Skip to content
Domain Specific Language

TL;DR-time: XSS & XSRF (web attack vectors)

  1. Prerequisites
  2. XSS in-depth-ish
  3. XSRF in-depth-ish
  4. Cross-origin resource sharing (CORS)
  5. Somewhat related reading

I'm going to explain Cross-site scripting (XSS) & Cross-site request forgery (XSRF/CSRF) to myself.


Super long names like "Cross-site request forgery" and their scary acronyms don't exactly lend themselves to instant revelations about how they work. Not like S.C.U.B.A., anyway.

Therefore we must know some things™. Welcome to the TL;DR section.

Mallory has her work cut out for her!


Basically, if your web page displays input from users, and that input is not scrubbed by you, that input could be weaponized — e.g. if it loads (or is) a script (yes, that was an em dash).

XSS generally applies when the user is interacting with your page directly.


Any page that you visit can load content from your web page via GET (and possibly other means if CORS is disabled, or when using XSS + XHR). All of this is perfectly valid, because many pages want to provide resources like images.

Loading an image can be done with an <img> tag. That <img> tag may point to ANY url on your site, and if your site uses cookies (or possibly other means of auth*), and you are still logged in, Mallory might start wreaking havoc.

XSRF generally applies when the user is not interacting with your page directly.

Combination of XSS & XSRF

Obviously, if the attackers can combine these methods, they might be more successful than when employing just one.

XSS in-depth-ish

Some examples will be given, followed by a section on protection. No guarantees can be given as it pertains to their efficacy.

XSS as a script in query parameters

This vector is generally called "non-persistent".

If the script is allowed to be included in a user-facing HTML the attacker can perform any action that the user is allowed to perform. An example of this is a query parameter name=your%20name that your page reads and displays as the title of some page. Now the attacker crafts some url<script>alert('xss')</script>, and voila you dad just got rekt. (The url can be further masked using character percent escaping).

XSS as a script in a forum post

This vector is generally called "persistent".

If you allow user input in a forum post, user support request ticket, etc. you may be subject to XSS attacks. The attack happens when Mallory is allowed to post user-facing HTML that is not sanitized using HTML escaping. Same scenario as in the non-persistent case — Your dad is going to get rekt; only this time he gets rekt every time he refreshes that forum post on gastrointestinal health.


Always sanitize external input. Always validate external input. Disable scripts in your browser (you're not going to do that though, are you, tough guy?). There's some stuff coming in future browsers too.

XSRF in-depth-ish

This guy made me read a lot of text, and I'm not going to put you through that.

We love to love cookies, and Mallory knows it. That <img> tag we talked about earlier, it might look like this: <img src=""/>. (You're probably not going to have an API like that but bear with me). That resource is going to be loaded using a GET request, and the browser is going to send your cookies right along with it. That's right, your dad just keeps getting rekt.


This guy has a novel approach to web browser security as it pertains to XSRF attacks: load every page that requires credentials separately and make sure no other web pages are loaded. Sign out a soon as you are finished. Oh, and restart your browser after signing out, who knows what might be cached? No one is going to do that though.

We're going to help your dad out, because he's a nice guy.

If you're not into TL;DR, there's this: OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet

Don't expose resource changing actions as GETs

Check the header for origin / referer

XSRF tokens

Or as this guy points out, anti-XSRF tokens, are a way to validate all requests by generating unique ids and appending them using e.g. hidden input fields in forms, or required request parameters. Optimally the id is generated per request, but for practical reasons (web apps) they can be per session, or alternatively cookies with a predefined, short, lifespan.

An example:

This attack is still subject to XSS + XSRF because the XSS would be able to read your cookie. Dad's getting rekt again.

Cross-origin resource sharing (CORS)

Since I mentioned CORS a few times, here's the lowdown:

CORS is used when a site is including e.g. images from a domain outside the domain from which the request originated. This is useful. Some servers might set Access-Control-Allow-Origin: *, e.g. the server serving google's fonts: <link href='' rel='stylesheet' type='text/css'>.

Somewhat related reading

Some stuff I stumbled across in this recent quest for knowledge:

Furthermore, you should see what some people that are probably smarter, more structured, and likely prettier than me had to say: