As per my understanding, while exploiting an XSS (in GET request) the attacker will craft the malicious link with a JS payload and will send it to the victim. When the victim clicks on the link the script will send the cookie to the attackers server.

How can I exploit an XSS vulnerability if the parameter is going in the body. How exactly should I create a payload (link or file) and send it to the victim?

  • 2
    Aren't you essentially asking on how to make the user submit a POST request with attacker controlled data and then show the resulting page to the user? Have you tried using a <form method=POST ... and make the use click on the submit button or similar? Dec 18, 2017 at 6:22

1 Answer 1


You can not craft a link that contains a POST body. So you will have to go a somewhat different route.

You will need to create your own page that contains the payload:

<form action="http://target.com" method="post" onload="this.submit()">
  <input type="hidden" value="payload" name="fieldname">

Or you can achieve the same effect just using the JavaScript fetch API. Then you need to trick the victim into visiting this page.

This will be a little bit harder since the URL will be different and perhaps look a bit fishy. If you want to avoid that, you can go looking for open redirect vulnerabilities and leverage them to take the victim to your page.

Of course, if the payload is stored on the server, and displayed on a page that can be visited later, this is much simpler - just make the victim visit that page. This is what is called stored XSS.

  • 1
    As per my understanding this would also require the page vulnerable to CSRF. Since posting cross-domain form with CSRF protection is not possible.
    – Rahul
    Nov 22, 2019 at 16:44
  • @Rahul The vulnerable page may even be stateless and without authentication, so CSRF is sort of a separate issue.
    – Anders
    Nov 22, 2019 at 18:06
  • 1
    Can you point towards such example ?
    – Rahul
    Nov 22, 2019 at 18:17
  • "As per my understanding this would also require the page vulnerable to CSRF." Not necessarily! CSRF, as typically described, only applies to state-changing requests. Not all POST requests are state-changing! For example, there is absolutely no need for search engine requests to use GET; they do because this makes it easy to bookmark or transmit a link to a search result page, but they could just as easily be POST... and if they were, they would not need CSRF protection (and almost certainly wouldn't have it, because that breaks other use cases).
    – CBHacking
    Mar 27, 2023 at 8:16
  • As for "stateless and without authentication", consider a site like, well, Google. Google has a few parts: there's the stateless and unauthenticated (or at least not-auth-requiring) search engine, and then there's all the authenticated parts (account management, mail, calendar, etc.). If they all share a common domain (which Google doesn't exactly do, but it does share a root domain which is often enough), then an XSS on the (anonymous) search page could probably be used to attack (authenticated) users on other Google services like Gmail (though in the real world hopefully that wouldn't work.)
    – CBHacking
    Mar 27, 2023 at 8:20

You must log in to answer this question.

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