Almost all of my XSS false positives come from Burp sending raw byte array payloads to the server and getting the same response injected into DOM or whatever. But in real world browsers automatically URL encode requests (RFC standard), and this is something Burp can't yet handle. Or at least I couldn't find it.

Do you have something for this? I'm talking about the Scanner explicitly.

I would've made an extension that implements IScannerInsertionPointProvider correctly, but as far as I know there's no way to apply it only for XSS payloads. There are some other vectors where non-urlencoded version is the one I want to use.

  • 2
    Just curious, why do you consider these as false positives? You don't want your server to rely on client-side (browser) protections like always URL encoding requests correctly.
    – Jedi
    Commented Aug 4, 2017 at 15:18
  • The client wants us to only report real risks. As far as I know, all major browsers url encode params, and of course you can't simply find someone with Netscape 3, send an URL to him and wow it executed. We were getting a lot of these XSSes lately, like hundreds of entries for a few applications, and it's really overwhelming to go and check them one by one - if I could just tell burp to act like a real browser... Commented Aug 5, 2017 at 10:56
  • Just because you cannot replicate it using a browser, doesn't mean it's not real. The Burp report should give you more details. Remember, an adversary is probably not going to be using a browser.
    – Jedi
    Commented Aug 5, 2017 at 13:34

1 Answer 1


It sounds like these are genuine findings.

Be aware that Internet Explorer does not encode less-than signs in URLs. Have a go at reproducing the finding using IE. If you are not able to, that indicates something else is going on.

If you need further assistance, please email [email protected] and include screenshots of a false positive.

  • Soliciting email replies is not accepted here. You may link to your web site or email address from your profile if you like, but it does not belong in this answer.
    – tripleee
    Commented Aug 7, 2017 at 8:23
  • If you are really from Burp support team (not the commercial team for instance...), your answer (more a comment than an answer btw) surprises me. Maybe you've read the OP question too fast, as the OP seems to complain that Burp doesn't escape special chars as genuine browsers do, however an attacker will precisely use raw, unescaped chars in order to exploit a server vulnerabilities. Attacker do not care of RFCs, on the contrary they will happily violate them as long as it allows to break into the target. Burp is just acting as expected. Commented Aug 7, 2017 at 8:31
  • @tripleee - Fair enough. We find that users are often unwilling to share useful diagnostic information like screenshots in public forums, so moving the conversation to email is useful. Commented Aug 7, 2017 at 8:53
  • 2
    @WhiteWinterWolf - This is the Burp support team; my personal account on here is paj28. I'm not quite sure why our answer surprises you. XSS vulnerabilities typically take place in a victim's browser. If all common browsers did encode in this scenario then this may well be a false positive. Pointing out the common browser that doesn't encode is indeed the answer to this question. Commented Aug 7, 2017 at 8:57
  • @PortSwigger: Ok, thanks for your comment, now I follow the reasoning behind your answer :) ! Commented Aug 7, 2017 at 9:04

You must log in to answer this question.

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