Is prevention of XSS a valid reason to prefer POST over GET for web apps?

The current trend in web applications seems to be towards using GET requests for everything. Specifically, using RESTful URLs that describe a service, a command, and its parameters. A few months ago, Jeff Atwood posted about the dangers of XSS. He demonstrated how even allowing users to post on your site something as seemingly innocuous as an "img" tag could result in an XSS vulnerability. The reason is that the browser will just go blindly request the url in the "src" attribute, which could do something merely annoying, such as logging the user out, or something much more ominous.

When I first started doing web development ten years ago, the conventional wisdom was to always favor POST over GET for forms, and to have the application on the server side require POST for form submission, for precisely this reason. Browsers send GET requests all the time (like in the aforementioned "img" tag example), but they only send POST requests in certain circumstances (specifically, forms with the "method" attribute set to POST). By requiring POST, is seems you can eliminate a large segment of XSS attacks. Is this a valid reason for preferring them?

From stackoverflow

• You're confusing vanilla Ajax calls with REST calls.

  Vanilla Ajax calls use GET or POST and it is completely up to you how to handle them.

  REST uses the verbs GET, HEAD, POST, PUT, DELETE

  HTTP VERB   REST/CRUD
  POST         Create
  GET          Read
  PUT          Update, Create
  DELETE     Delete
  

  You want to use POST over GET when you are worried about CSRF, not XSS.

  A good rule of thumb is always use POST and only use GET if you are absolutely sure you want to share that data with other sites or the data is not sensitive.

  But just using POST alone won't protect you 100%.

  Both XSS and CSRF are very important and you should review your app for both, but they are two very different beasts.

  CSRF :

  Wikipedia

  OWASP

  XSS:

  OWASP

• I think you're misunderstanding REST. The point isn't to prefer GET over POST, the point is to use GET where the request doesn't affect the data on the server, and POST where data is modified. REST is all about properly using the HTTP verbs available.

  For example, a search form will often use GET, while a Create X form will usually use POST.

  Chad Grant : You're totally missing the security aspect in your answer :(

• Since when did REST imply using GET for everything? Last I checked, it meant the exact opposite. Use GET requests for getting a resource, and POST for posting one to the server.

  One of the key points of REST is to use the HTTP requests that best maps to the operation you're trying to do. GET should be used for what it is intended for: Getting data from the server, without changing state on the server. It should not be used to update resources on the server. POST or PUT are designed for that.

  Using HTTP the way it was intended to be used both helps avoid some (but far from all) XSS attacks, it also makes browsers behave a lot nicer when communicating with your site. The browser expects that GET requests can be safely repeated, without requiring confirmation from the user. That's what it does if you refresh the page, for example, or use the back/forward buttons. POST is expected to change state on the server, so the browser typically asks for confirmation before repeating a POST request.

  Chad Grant : Restricting POST will have absolutely NO effect on XSS. XSS is caused by not validating the data you receive from the client regardless if that data comes from GET or POST. This particular question is more about CSRF

• Anyone can set up a simple html form and 'POST' data to your webservice via their browser and the local html file.

  Restricting to POST will stop simple xss but if they can get a javascript running it won't really change much.

  From my experience GET is mainly used for 'getting' stuff from the server, post is used for 'posting stuff' to the server.

  GET's Have the ability to be bookmarked simply and clearly.

  POST's can hold much more data due to not being restricted by the max url length which you should be trying to keep small.

  Chad Grant : Restricting POST will have absolutely NO effect on XSS. XSS is caused by not validating the data you receive from the client regardless if that data comes from GET or POST

• There are situations when you should use POST rather than GET, but avoiding XSS isn't one of them. Perhaps you're thinking of XSRF, but even then, requiring POST doesn't really protect you. And in fact, REST advocates would actually say that you shouldn't just use GET but that you should use POST, PUT and DELETE for the corresponding "CRUD" operations.

  To avoid XSS, escape and/or scrub content from users appropriately.

  To avoid XSRF, require secret tokens on any side-effect causing operation that is potentially dangerous. (BTW: it's a good idea to avoid using GET requests when passing secret tokens as this could result in them leaking in referrers.)

  Use GET for read-only requests whenever possible. (pretty much whenever the query can fit in a URL)

  Use POST (or PUT or DELETE, if feasible and appropriate) for write requests.

• XSS won't be stopped; XSS is when a user gets you to somehow output their script to other users. That requires filtering.

  XSRF won't be stopped either; it requires adding one-time-tokens of some sort, to ensure that someone can only hit your site if they're actually on it (rather than posting from an embedded iframe or the like).

  However, POST vs GET does prevent web accelerators and scrapers (eg Google Bot) from modifying your site. They only go to GET links, and thus if you don't want to have your site deleted (a la Daily WTF posts on this), make sure that 'delete this item' isn't a GET. ;-)

  More usually, it's a matter of semantics and form size. GET does not post a form, thus is limited to whatever you can put in a URL, which is not much. POST allows arbitrary amounts of data. PUT and DELETE are more there for semantics; they can both be done via POST too.

• The already-given answers really do answer your question - no, prevention of XSS is not a valid reason to prefer POST over GET. However, if you want a demonstration of this, check out tools like WebScarab or Tamper Data, which are very useful for testing your own site's vulnerabilities. It's just as easy to inject code into a POST request as into a GET. Even without these tools, though, note that unless you're checking for POST vs. GET server-side, it's easy to simply send parms using a GET. Simply add, e.g., ?parm1=value1&parm2=value2&etc to the URL.