When you examine the network panel on a webpage containing scripts, images, stylesheets or fonts, you will notice that all requests are made using the GET HTTP method. For example, a request for a file loaded by a <script> tag will appear as follows:
https://i.sstatic.net/79zz0.png
Similarly, an example of a file loaded by an <img> tag will look like this:
https://i.sstatic.net/agsMu.png
The browser trusts that if you are loading such resources, you understand the implications, allowing content delivery networks (CDNs) to function effectively. This stands in contrast to XHR requests!
XHR requests (including fetch calls) are subject to CORS policy checks, which restrict JavaScript from making requests for resources on different domains or ports.
In summary, there are two types of request policies:
- XHR requests are CORS-checked, but allow any HTTP request method.
- Requests made using
img, script, link, etc., are not subjected to CORS policy checks but are limited to GET HTTP requests only. Cookies, including authentication ones, are sent along with these requests.
This means that if you serve a JSON array via a GET request, you can utilize a script tag to fetch and execute it regardless of the domain. By leveraging the technique mentioned in the article, sensitive information can be accessed in this manner.
If you were to use POST, attackers would be unable to perform such requests through a script tag since they rely on GET requests for resource fetching.
You may consider using a form element, but CORS limitations still apply. Submitting a form loads the JSON data into the current page, preventing attackers from accessing it after the script is removed.
Even setting the form target to an iframe proves futile, as JavaScript blocks access within that iframe.
Does this explanation clarify things?