A Brief XSS Scanning with Burp Suite

Web application security testing is not the topic of one article, it takes a whole book. So I will focus only on the example of scanning for XSS (cross-site scripting) with one special tool — Burp Suite.

You can try to find XSS vulnerabilities manually, but it won’t be productive and efficient. Testing for XSS is a kind of brute-force search — a repetitive scanning (or attacking) with changing of various parameters and payloads. Such tasks should be solved with a special tooling that allows us to check hundreds of test cases in a relatively short time.

1. Prepare the Burp Suite

I will use Mac OS Big Sur 11.6.4, Burp Suite Community Edition 2022.3.6 and Firefox 100.0.

  1. Download and install Burp Suite Community Edition;
  2. Run Burp Suite Community Edition and choose on the start screen: Temporary project → [Next] → Use Burp defaults → [Start Burp]
  3. Check Burp’s proxy settings: Proxy → Options → Proxy Listeners. Burp’s proxy should listen
Burp Proxy
Burp Proxy

4. Install Burp’s certificate for Firefox by instruction;

5. Сonfigure Firefox’s proxy settings: Preferences → General → Network Settings → [Settings…] → choose «Manual Proxy Configuration»: HTTPS = and Port = 8080 → [OK]

Firefox Connection Settings
Firefox Connection Settings

6. For further work of the «browser-Burp» bundle you need to turn off the Intercept: Proxy → Intercept → [Intercept is on]. Button should be = [Intercept is off]

Burp Intercept
Burp Intercept

Now, when you open a target page (I choose the official site of Formula 1) in Firefox, all connections from the page will pass through Burp and be logged:

Burp Logger
Burp Logger

Remark: If your target site is an internal environment inside a company’s VPN under IPv6, you should go: Project Options → HTTP → HTTP/2 and turn off «Default to HTTP/2 if the server supports it».

2. Prepare payload

To scan for vulnerabilities you need to have «vectors» for attack. The most significant XSS vectors are listed in OWASP’s XSS Filter Evasion Cheat Sheet.

To have only a few vectors is not enough for such kind of testing — you need different sets of payloads aimed at bypassing certain defensive filters — you do not know in advance which one will «work».

For this example I composed a payload list from the articles «XSS that works in 2021» and «New XSS vectors»:

More payloads:

3. Start test attack

The most simple attack (or scan) can be made through Burp’s Intruder by this steps:

  1. Refresh a target page in the browser;
  2. Open: Burp → Logger;
  3. Find a root HTTP/HTTPS request to the target page;
  4. Choose «Send to Intruder» in the request’s menu:
Send to Intruder
Send to Intruder

5. Open: Burp → Intruder. You will see the full request which was made by browser. All request’s variables will be marked by § identifiers:

Burp Intruder

6. Clear all identifiers: [Clear §]

7. Add two identifiers after GET / — GET /§§ — this means that the values from the payload list will be embedded inside §§:

Payload Positions
Payload Positions

8. On the «Payloads» tab paste from the buffer or load from a file your payload list:

Payload Options
Payload Options

9. On the «Payloads» tab turn off encoding to use all vectors unchanged;

10. On the «Options» tab reduce the number of retries = 0 (in order not to slow down the run in case of errors) and click [Start attack]:

Start attack
Start attack

11. In a new window you will see the progress of your attack:

Intruder attack

If the status code will be different from 200 or 404 and the request length will have a suspicious value — this means that you need to look closely at this request and try to reproduce it manually — a bug or vulnerability is somewhere close.

4. Explore

Nothing interesting was found in the example above — it was just an introduction to starting Burp Suite’s scans.

To find something worthwhile you should:

  • Take a closer look at the URLs with parameters;
  • Attack different request’s values (user-agents, cookies, session_ids or any custom headers);
  • Attack requests with authorization;
  • Attack POST requests with payloads in a body;
  • Combine different payload lists;
  • Use SQL injections instead of XSS payloads.

Example of a brief explore:

  1. There was an odd parameter a tag’s name in the URL:

2. I marked this parameter by identifiers in the Intruder and started attack;

3. I changed a few payload lists until the vector in one of it was triggered 400 status code:

Results: Request & Response

4. Reproducing this request in a browser leads to the error:


This means that the web application does not handle % in URL. The real attacker could use this knowledge to continue the attack.




Quality assurance engineer

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

xSNX Post Mortem

Efinity turns into the winner of Polkadot’s sixth parachain public sale


Securing your A$$-ets in Web3

Zero Logon TryHackme Writeup

{UPDATE} Syzygy Tablebase Hack Free Resources Generator


{UPDATE} Vector for iPhone Free Hack Free Resources Generator

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Andrey Enin

Andrey Enin

Quality assurance engineer

More from Medium

My write-up in hacking IBM’s administration panel and getting SQLi on it

OWASP — UnCrackable Level 1

Stored XSS into HTML

Blind SQL injection with time delays and information retrieval(portswigger)