title: Why Same-origin policy isn't enough to prevent CSRF attacks?
body: <p>First of all, I assume a backend that control inputs to prevent XSS vulnerabilities.</p>
  
  <p>In <a href="https://stackoverflow.com/a/28953341/3517383">this answer</a> @Les Hazlewood explain how to protect the JWT in the client side.</p>
  
  <blockquote>
    <p>Assuming 100% TLS for all communication - both during and at all times
    after login - authenticating with username/password via basic
    authentication and receiving a JWT in exchange is a valid use case.
    This is almost exactly how one of OAuth 2's flows ('password grant')
    works.
    [...]</p>
    
    <p>You just set the Authorization header:</p>
  
  <pre><code>Authorization: Bearer &lt;JWT value here&gt;
  </code></pre>
    
    <p>But, that being said, if your REST client is 'untrusted' (e.g.
    JavaScript-enabled browser), I wouldn't even do that: any value in the
    HTTP response that is accessible via JavaScript - basically any header
    value or response body value - could be sniffed and intercepted via
    MITM XSS attacks.</p>
    
    <p>It's better to store the JWT value in a secure-only, http-only cookie
    (cookie config: setSecure(true), setHttpOnly(true)). This guarantees
    that the browser will:</p>
    
    <ol>
    <li>only ever transmit the cookie over a TLS connection and,</li>
    <li>never make the cookie value available to JavaScript code.</li>
    </ol>
    
    <p>This approach is almost everything you need to do for best-practices
    security. <strong>The last thing is to ensure that you have CSRF protection on
    every HTTP request to ensure that external domains initiating requests
    to your site cannot function.</strong></p>
    
    <p>The easiest way to do this is to set a secure only (but NOT http only)
    cookie with a random value, e.g. a UUID.</p>
  </blockquote>
  
  <p>I don't understand why we need the cookie with the random value to ensure that external domains initiating requests to your site cannot function. This doesn't come free with Same-origin policy? </p>
  
  <p>From <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Viewstate_.28ASP.NET.29" rel="noreferrer">OWASP</a>: </p>
  
  <blockquote>
    <p>Checking The Origin Header</p>
    
    <p>The Origin HTTP Header standard was introduced as a method of
    defending against CSRF and other Cross-Domain attacks. Unlike the
    referer, the origin will be present in HTTP request that originates
    from an HTTPS url.</p>
    
    <p>If the origin header is present, then it should be checked for
    consistency.</p>
  </blockquote>
  
  <p>I know that the general recommendation from OWASP itself is Synchronizer Token Pattern but I can't see what are the vulnerabilities that remains in:</p>
  
  <ul>
  <li>TLS + JWT in secure httpOnly cookie + Same-origin policy + No XSS vulnerabilities.</li>
  </ul>
  
  <p><strong>UPDATE 1:</strong>
   The same-origin policy only applies to <a href="https://stackoverflow.com/a/9033631/3517383">XMLHTTPRequest</a>, so a evil site can make a form POST request easily an this will break my security. An explicit origin header check is needed. The equation would be:</p>
  
  <ul>
  <li>TLS + JWT in secure httpOnly cookie + <strong>Origin Header check</strong> + No XSS vulnerabilities.</li>
  </ul>