So I essentially went on an epic voyage to figure out how to implement CSRF tokens. 20 years later - and now I feel like I just wasted my life. haha

So basically after making malicious test-clients and doing some re-reading it looks like it's virtually not a problem if:

1) You don't allow outdated browsers(they don't enforce CORS) 

2) You don't allow CORS by setting the "Access-Control-Allow-Origin" on the resources.

3) You use a JSON API(all requests-responses is sending JSON).

4) You take care of XSS(they can inject code that will run from same origin ).

So as long as you take care of XSS(Reactjs! Holla) - all of the above(minus the old browser part I guess) is basically common practice and an out-of-the-box setup - so it seems like a waste of time to worry about csrf tokens.

**Question:**

**So in order to avoid throwing my laptop under a moving car - is there any reason that I did all that work adding CSRF tokens if I am already adhering to the 4 prevention strategies mentioned above?**

---

Just Fun Info - wanted to share one juicy find my tests came across:

The only ify thing I found with my tests is "GET" requests and an image tag

e.g.

```
<img src="http://localhost:8080/posts" onload={this.doTheHackerDance} />

```

The above will pass your cookie, and therefore access the endpoint successfully, but apparently since it is expecting an image - it returns nothing - so you don't get to do the hacker dance. :)

BUUUUT if that endpoint does other things besides return data like a good little "GET" request(like update data) - a hacker can still hit a "dab!" on ya (sorry for viral dance move reference).

---