CORS on an's security blog

CORS vulnerability with trusted insecure protocols | Practitioner

Tue, 07 Jul 2026 13:43:16 +0800

Just like the last lab, the session cookie has SameSite=None and there is zero CSRF tokens or anything of the sort while querying for sensitive data on /accountDetails: But unlike the last two labs, the web application here controls which origins can get in quite strictly. It withstands parsing errors and the null check, which would prove exfiltrating victim’s data more difficult.

So naturally, we should probe other functionalities to find an attack surface. Notice the Check Stock add-on, is it rather odd that whenever we want to query stocks, it opens a window to an insecure HTTP subdomain? Plus, this possibly vulnerable subdomain is on the whitelist, maybe this is our attack surface: Upon closer inspection, to access stock level we do need to provide two necessary params productId and storeId. The site dictates the former must definitely be an integer, what if it isn’t? Rather than showing a generic error message, the web application on this subdomain reflects our wrong ID into the HTML. This smells of XSS vulnerabilities, let’s test this by adding a harmless h1 tag: Surprisingly this works! We can inject arbitrary HTML and the parser will honor it. Using all these information in mind, we can just paste our old payload into productId and it will run smooth as butter:

CORS vulnerability with trusted null origin | Apprentice

Tue, 07 Jul 2026 10:39:16 +0800

Similar to this lab, the session cookie still has SameSite=None and sensitive data is still stored at the /accountDetails endpoint. CORS may still be supported as the Access-Control-Allow-Credentials is set to True:

Let’s try manipulating the Origin header, for example say evil.com? The request is accepted? Yet there is no Access-Control-Allow-Origin header which means the origin is rejected? What does this mean? Turns out that CORS is enforced by the victim’s web browser, and not the server.

CORS vulnerability with basic origin reflection | Apprentice

Tue, 07 Jul 2026 09:43:16 +0800

Our goal is to obtain the API key of administrator, so first we have to see how it is returned in the response: The web application fetches the endpoint /accountDetails including the user’s credentials. It then queries for apiKey and reflects it in the HTML. This sounds interesting, let’s dive in for more! The backend returns with a clean JSON object containing our apikey and session cookie as well, this smells privacy issues. Not only that the web application responds with the Access-Control-Allow-Credentials header set to True, meaning CORS may be supported and credentials are included in requests for the same origins at least. Let’s try spoofing the Origin header and see what’s up: Surprisingly, the backend never bothers validating origin and just appends them blindly into the Access-Control-Allow-Origin header, not only that but we are also allowed to send credentials into our requests as well. This opens up opportunities for a CORS exploit on the /accountDetails endpoint, but we forgot to check whether the session cookie is Strict or not. Let’s try: Thankfully, the session cookie is set to None, and since our original request does not have CSRF tokens, we can craft the following payload: