Clarify CORS validation in 3.4.2 to explicitly reject 'null' origin

[Galaxy-sc]

Requirement Referenced

3.4.2 - Browser Security Mechanism Headers

Description of the Issue

The current text for requirement 3.4.2 mandates validating the Origin header against an allowlist but does not explicitly warn against accepting the null origin.

The null origin is a specific edge case generated by browsers in scenarios such as sandboxed iframes or local file access. If an application's allowlist is not strict enough (or if it reflects the origin blindly), an attacker can use a sandboxed iframe to bypass CORS policies by sending Origin: null.

Proposed Change

I propose updating the requirement text to explicitly mention rejecting null unless it is strictly required by the architecture.

Current Text:

...validated against an allowlist of trusted origins. When 'Access-Control-Allow-Origin: *' needs to be used...

Proposed Text:

...validated against an allowlist of trusted origins (specifically rejecting the null origin unless strictly required). When 'Access-Control-Allow-Origin: *' needs to be used...

Motivation

This clarification ensures that developers and security testers specifically verify that the application does not inadvertently allow the null origin, closing a common bypass vector for CORS protections.

[elarlang]

The requirement 3.4.2 as it is at the moment:

#	Description	Level
3.4.2	Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header field is a fixed value by the application, or if the Origin HTTP request header field value is used, it is validated against an allowlist of trusted origins. When 'Access-Control-Allow-Origin: *' needs to be used, verify that the response does not include any sensitive information.	1

Well, I agree that the null option is not specially highlighted, but...

The current text for requirement 3.4.2 mandates validating the Origin header against an allowlist but does not explicitly warn against accepting the null origin.

If the null is not "your fixed value" or in your allow list, it is not allowed anyway.

The null origin is a specific edge case generated by browsers in scenarios such as sandboxed iframes or local file access. If an application's allowlist is not strict enough (or if it reflects the origin blindly), an attacker can use a sandboxed iframe to bypass CORS policies by sending Origin: null.

I think this is most likely the scenario for the "null" support - it is not supported as a special solution for the "null" value, but it is supported (as a side effect) if the Origin request header field value is blindly reflected back as the value of Access-Control-Allow-Origin response header field. Without that general problem, it requires special bad-intended development to have support for "null".

So, for the Access-Control-Allow-Origin and (not) allowing the cross-origin party to be able to read the response is covered for me.

Support for the proposed modification comes from a different problem to solve - if defense against "browser-based request forgery" (or known as cross-site request forgery, CSRF) relies on CORS, then accepting null can happen more likely, as accepting the malicious cross-origin request does not require the ability to read the response. It is a separate requirement (v5.0.0-3.5.2), it basically requires conditions from v5.0.0-3.4.2 to be satisfied for accepting the request.

[Galaxy-sc]

Thanks @elarlang for the detailed breakdown. I appreciate the distinction between 3.4.2 (headers/confidentiality) and 3.5.2 (CSRF/integrity).

However, I believe adding an explicit check for null in 3.4.2 is still valuable for the following reasons:

1. Confidentiality Risk (Data Leakage): You mentioned 3.5.2 covers the "request acceptance" (CSRF) aspect. But 3.4.2 is about preventing unauthorized origins from reading the response. If an application blindly reflects null (or incorrectly whitelists it due to local development configurations), an attacker using a sandboxed iframe can indeed read the sensitive response data. This directly violates the objective of 3.4.2.

2. Testing Guidance: While a theoretical "perfect allowlist" excludes null, in practice, developers often use weak Regex or logic like if (origin == "null") return true; for local file testing and forget to remove it. Explicitly mentioning null guides the verifier/tester to specifically inject Origin: null to ensure the application doesn't accidentally allow it. It turns an implicit assumption into an explicit test case.

3. Reflected Origin vs. Null: You are right that "Blind Reflection" is the root cause. But null is the specific payload that often slips through because it doesn't look like a typical malicious domain (e.g., evil.com). Highlight it ensures it's not overlooked during implementation or verification.

Would you be open to a slightly softer phrasing? For example adding a note: "Ensure that the allowlist does not accept the 'null' origin unless explicitly required."

[elarlang]

The motivation here is more to keep requirements as short as possible and cover all necessary areas at the same time. We deliberately are not too prescriptive and also are not intended to be a testing guide (see What is ASVS).

So that is why I would say that requirement 3.4.2 as it is at the moment, covers all the raised concerns, and there is no "problem in principle" to solve.

In short, I don't think we need to make the change, but I don't mind as well. Let's see what others may think here.

[Galaxy-sc]

Understood. I appreciate the open-mindedness.

Since there is no objection in principle, I will proceed to fix the formatting issues in the PR (removing the code blocks as requested) to make it compliant with the contribution guidelines. This way, it is ready for review if others agree it adds clarity.

[jmanico]

If you build a reasonable allowlist of origins, the null problem is "solved". I think this threat, while important, is not enough to modify this existing requirement.

[Galaxy-sc]

Hi @jmanico, thank you for the feedback.

I completely agree that a strictly implemented allowlist inherently solves the null origin problem.

However, the motivation behind this proposal is defense against implementation flaws. In real-world assessments, we frequently see developers inadvertently allowing null (often for local development convenience) or blindly reflecting the Origin header, assuming that validating the domain format is enough.

Since ASVS is a verification standard used by testers, making the null check explicit serves as a reminder to verify this specific edge case, which automated scanners often miss.

If you feel this adds too much verbosity to the core requirement, I understand and respect that decision. In that case, do you think this distinction belongs better in the WSTG (Web Security Testing Guide) rather than ASVS?

[jmanico]

I do indeed think the WSTG is the right place for this nuance.

Since an allowlist inherently solves the null origin problem, I politely think it's ok to keep the ASVS requirement as is.

At this state, taking a cue from @elarlang - we only want to make changes to the existing standard if necessary. I politely do not think this is one of those necessary additions.

[Galaxy-sc]

Thank you @jmanico and @elarlang for the review and the clear guidance.

I understand the perspective of keeping ASVS concise and focusing on the core requirement (allowlist) rather than specific edge cases. I agree that the WSTG is the more appropriate place to document this specific testing nuance.

I will close this issue and the associated PR. Thanks again for your time.

[elarlang]

I'm not concerned about ACAO, but I reopen the issue for the request forgery motivation, as I stated in #3322 (comment)

Support for the proposed modification comes from a different problem to solve - if defense against "browser-based request forgery" (or known as cross-site request forgery, CSRF) relies on CORS, then accepting null can happen more likely, as accepting the malicious cross-origin request does not require the ability to read the response. It is a separate requirement (v5.0.0-3.5.2), it basically requires conditions from v5.0.0-3.4.2 to be satisfied for accepting the request.