Frontend - Add a confirmation modal when clicking on new links

[ValentinRegnault]

Feature Request

Is your feature request related to a problem or unsupported use case? Please describe.
A common phishing technique is to disguise a malicious link as a legitimate one using an <a> element with a misleading href. For example:
<a href="http://malicious.com">http://safe.fr</a>
This appears to the user as a link pointing to safe.fr, while it actually redirects to malicious.com.

Describe the solution you'd like
When a user clicks on a link, display a confirmation modal showing the actual target URL (href) before redirecting.

Possible improvements:

1. Fetch the link beforehand and, if the response status is a 3XX (redirection), display the final destination URL.
2. Add a checkbox such as “Always trust this domain”, so that future clicks on links from the same domain bypass the confirmation step.

Describe alternatives you've considered
Marking emails that contain disguised links as spam. This can work for simple cases like
<a href="http://malicious.com">http://safe.fr</a>,
but it does not cover more advanced attacks, such as mimicking a company’s design system (e.g., fake buttons) that redirect to malicious domains.

Discovery, Documentation, Adoption, Migration Strategy
The feature is self-explanatory and should be intuitive for users, as it integrates directly into the link-clicking workflow.
Here is a quick design mockup:

Do you want to work on it through a Pull Request?
Yes!

As part of a course on free and open source software, I am required to contribute to a project, and I would be happy to work on implementing this feature.

[sylvinus]

Great idea. Adding an additional warning when the underlying text is different, as @mosa-riel suggested is a good enhancement too.

[mosa-riel]

Great idea.

A couple of thoughts on making it practical without overcomplicating things:

Trusted domain allowlist
Not every link needs a popup. Links pointing to the organization's own domains like other La Suite applications or internal tools that share document links could be allowlisted so users aren't interrupted on every click. This could be a configurable list in the instance settings, and ties in nicely with the "Always trust this domain" checkbox idea from the issue description.

Optional malicious link detection via DNS-over-HTTPS
As a separate, (opt-in?) enhancement, the backend could check the link's domain against a security-filtering DNS resolver using DNS-over-HTTPS. Services like Quad9 (Swiss non-profit, GDPR-compliant, no API key needed) block known malicious domains at the DNS level. If the domain is flagged, the modal could show a stronger danger warning instead of the neutral confirmation. This should be kept optional so the core modal can land first without added complexity.

So the flow could be:

1. User clicks a link → domain is in the trusted allowlist → open directly
2. Not trusted → show confirmation modal with the actual target URL
3. (Optional, if enabled) Domain is flagged by DNS check → upgrade the modal to a danger warning

Happy to help think through this further if useful!

[ValentinRegnault]

Thank you for your feedback.

Having a configurable default list at instance level is a great idea. Do you think the 'Always trust this domain' checkbox should whitelist the domain at instance level too? Instead, I was thinking of a peer-user whitelist (adding a new model called 'TrustedDomains' with a foreign key referencing a user).

Integrating Quad9 would be a really cool improvement!

[mosa-riel]

There is a trusted setting about image proxy - is that usable to hook on?

[ValentinRegnault]

I’m not sure I understand what you’re referring to 🤔

In the environment variables, you can define variables related to the image proxy:

Variable	Default	Description	Required
IMAGE_PROXY_ENABLED	False	Whether external images should be proxied	Optional
IMAGE_PROXY_MAX_SIZE	5242880 (5MB)	Maximum size in bytes for external images	Optional
IMAGE_PROXY_CACHE_TTL	2592000 (30 days)	Cache TTL in seconds for external images	Optional

But I don’t see the connection with trusted domains

[mosa-riel]

Sorry, it is not implemented but this issue:

#510

But it could be an option for later. Since you would have the same questions for links as for images - you manage it somewhere.

[ValentinRegnault]

Yes, it would be great to have a way to edit users' personal domain whitelists. Perhaps this could be added to the settings menu in the top-right corner of the screen?

I’m thinking of implementing this by creating a new model, say TrustedDomain, with:

• an id
• a domain_name field
• a user foreign key referencing the User model

Then I could add the following routes:

• GET /api/v1.0/trusted-domains/ to return the user’s whitelist
• POST /api/v1.0/trusted-domains/ to add a new domain to the whitelist
• DELETE /api/v1.0/trusted-domains/{id} to delete a domain from the whitelist

Does this approach sound like a good idea to you?

[mosa-riel]

Should we separate the trusted domains based on the implementation? So we can separate domains for links or images? Further thinking we could even whitelist domains for delivery (e.g. always deliver regardless of spam score). So maybe this white/blacklisting should be a separate issue that we can hook later to these and focus here on the functionality itself? We could make sure we take it in mind.

[sylvinus]

Not sure we already want a new model just for that. Probably a static list in settings is fine (with support for star-matching) to start with?