-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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.
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
Target blank dynamic link should fail #1784
Target blank dynamic link should fail #1784
Conversation
I think that since it can generate false positives, it should be behind an option. |
Makes sense to me. I’ll update the pull request.
…On Sat, May 12, 2018 at 1:09 PM Jordan Harband ***@***.***> wrote:
I think that since it can generate false positives, it should be behind an
option.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1784 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAHxOftjxo6OG3Av3nU9MQ22TbUS1azTks5txyVIgaJpZM4T8FR9>
.
|
@ljharb I've added the option and set "always" as the default since it seems the safer state. One thing I noticed is that you still would not get the error if you assigned the href using the spread operator to assign the href prop. Should that be covered in another option? |
I think if you can expand the error so it applies to an inline spread-"href", that would be generally useful? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
To be fair, if you set ALL your props within an object (eg. target, rel, etc) and then use the spread, it would bypass all these checks. Am I right? |
Yes, that's generally true - but spreading props is an antipattern anyways, so it also might be OK to allow the checks to be bypassed in that case. |
Thanks, @kenearley, for moving this along. The whole idea of the vulnerability is when untrusted link is added without "rel=noopener". When the link is hard-coded, it's most likely trusted. Otherwise, why would you add untrusted links to your application. Untrusted links will most likely come from user input. Anyway, I'm glad this is added. |
Made from the suggestion in @ksdmitrieva's issue, I believe this is the right approach even though you would get false positives since it cannot check for relative paths in dynamic links. However, I think that would be rare since it's not best practice to use
target='_blank'
on internal links anyway.