Skip to content

[HtmlSanitizer] Add support for securing target="_blank" links #60539

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

[HtmlSanitizer] Add support for securing target="_blank" links #60539

wants to merge 1 commit into from

Conversation

Spomky
Copy link
Contributor

@Spomky Spomky commented May 25, 2025 •
edited
Loading

Q A
Branch? 7.4
Bug fix? no
New feature? yes
Deprecations? no
Issues Fix #
License MIT

Introduce ensureSafeBlankTarget to automatically add rel="noopener noreferrer" to <a> elements with target="_blank", mitigating reverse tabnabbing risks.

<!-- Before -->
<a href="https://site.example" target="_blank">Outgoing link</a>


<!-- After -->
<a href="https://site.example" target="_blank" rel="noopener noreferrer">Outgoing link</a>

The allowUnsafeBlankTargets method allows opting out of this behavior if needed.

ℹ️ Info: Modern browsers already consider noopener event if missing. However the presence of the rel attribute is still considered as [a good practice]
(https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html#tabnabbing) by the OWASP.
⚠ Warning: I modified Node::setAttribute to allow overwriting existing attributes. I might have missed the reason for the comment Always use only the first declaration (ease sanitization).
⚠ Warning: The logic is implemented in DomVisitor. It works, however I am wondering if an abstraction is needed.

@Spomky
[HtmlSanitizer] Add support for securing target="_blank" links
edc1bcc 
Introduce `ensureSafeBlankTarget` to automatically add `rel="noopener noreferrer"` to `<a>` elements with `target="_blank"`, mitigating reverse tabnabbing risks. The `allowUnsafeBlankTargets` method allows opting out of this behavior if needed. Included tests validate the new functionality.
@carsonbot carsonbot added this to the 7.3 milestone May 25, 2025
@carsonbot
Copy link

Hey!

Thanks for your PR. You are targeting branch "7.3" but it seems your PR description refers to branch "7.4".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

@Spomky Spomky mentioned this pull request May 25, 2025
Open
@nicolas-grekas
Copy link
Member

/cc @tgalopin can you please check this PR?

@fabpot fabpot modified the milestones: 7.3, 7.4 May 26, 2025
nicolas-grekas
nicolas-grekas reviewed May 30, 2025
View reviewed changes
Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm mixed on this one: browsers already implement the mitigation.
When people will upgrade to Symfony 7.4, even more people will have upgraded to a recent enough browser.

To me, this feels like a niche and dying concern. People that care should configure the sanitizer on their own so that we can keep the code simpler IMHO.

src/Symfony/Component/HtmlSanitizer/Visitor/Node/Node.php
@@ -58,10 +58,7 @@ public function getAttribute(string $name): ?string

public function setAttribute(string $name, ?string $value): void
{
// Always use only the first declaration (ease sanitization)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like we really understand what this means before removing.

@Seldaek
Copy link
Member

Seldaek commented Jun 2, 2025

I agree this isn't really needed, considering doing this only requires this (or similar):

            ->forceAttribute('a', 'rel', 'nofollow noindex noopener')

Of course this will apply to all links and not just target=_blank ones, but I think this is probably safer. Why should other targets not have the noopener flag? They open in a new window too, so IMO this PR introduces a vulnerability.

@Spomky
Copy link
Contributor Author

Spomky commented Jun 2, 2025

OK noted. Many thanks for your feedback.
So let's close it.

@Spomky Spomky closed this Jun 2, 2025
@Spomky Spomky deleted the features/safe-target-blank branch June 2, 2025 13:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nicolas-grekas nicolas-grekas nicolas-grekas left review comments

Assignees
No one assigned
Labels
Feature HtmlSanitizer Status: Needs Review
Projects
None yet
Milestone
7.4
Development

Successfully merging this pull request may close these issues.
5 participants
@Spomky @carsonbot @nicolas-grekas @Seldaek @fabpot