ascanrulesBeta: reduce CORS Scan Rule severity for 4xx/5xx responses#6990
ascanrulesBeta: reduce CORS Scan Rule severity for 4xx/5xx responses#6990rmtsixq wants to merge 3 commits intozaproxy:mainfrom
Conversation
- Check HTTP status code before evaluating risk level - Error responses (4xx/5xx) now result in INFO level alerts instead of HIGH/MEDIUM - Added unit tests for error status code handling - Fixes issue where 401, 404, 415 etc. were incorrectly flagged as high severity
|
All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
|
Great job! No new security vulnerabilities introduced in this pull requestUse @Checkmarx to reach out to us for assistance. Just send a PR comment with Examples: |
kingthorin
left a comment
There was a problem hiding this comment.
The CHANGELOG.md should also be updated.
addOns/ascanrulesBeta/src/main/java/org/zaproxy/zap/extension/ascanrulesBeta/CorsScanRule.java
Outdated
Show resolved
Hide resolved
addOns/ascanrulesBeta/src/main/java/org/zaproxy/zap/extension/ascanrulesBeta/CorsScanRule.java
Outdated
Show resolved
Hide resolved
|
Thanks for the feedback! I've updated the implementation to lower the alert confidence instead of the risk for error responses, as error pages may still expose sensitive information but exploitability is less certain. I've also switched to using isClientError/isServerError and updated the CHANGELOG and tests accordingly. |
|
Changed to draft since it requires more work as per zaproxy/zaproxy#9183 (comment) (feel free to mark ready once done). |

Summary
This PR fixes a false-positive in the CorsScanRule where CORS misconfigurations were being reported as HIGH or MEDIUM severity even when the target server responded with an error status (4xx or 5xx).
Error responses do not expose sensitive content, so the alert severity should not be escalated.
Problem
The original CORS Scan Rule logic evaluated ACAO/ACAC headers without considering the HTTP status code.
As a result, responses like 401 Unauthorized, 404 Not Found, or 415 Unsupported Media Type triggered high-severity alerts even though no sensitive content could be accessed.
This generated misleading scan reports and noise for users.
What This PR Changes
Adds a check for error status codes (>= 400) before evaluating alert severity.
If the response is an error, severity is now set to INFO.
Keeps existing severity logic for 2xx responses (intended behavior).
New Logic:
int statusCode = respHead.getStatusCode();
boolean isErrorResponse = statusCode >= 400;
if (isErrorResponse) {
risk = Alert.RISK_INFO;
} else if (acaoVal.contains("*")) {
risk = Alert.RISK_MEDIUM;
} else if (acaoVal.contains(RANDOM_NAME) || acaoVal.contains("null")
|| (secScheme && acaoVal.contains("http:"))) {
risk = acacVal.isEmpty() ? Alert.RISK_MEDIUM : Alert.RISK_HIGH;
}
Tests Added
Two new parameterized tests were added to ensure correct behavior:
shouldAlertInfoIfErrorStatusCodeEvenWithAcaoAndAcac
shouldAlertInfoIfErrorStatusCodeWithWildcardAcao
These tests verify that 4xx/5xx responses now correctly produce INFO alerts regardless of ACAO or ACAC configuration.
Impact
Prevents misleading HIGH/MEDIUM alerts on authenticated resources or unavailable endpoints.
Reduces false positives for users scanning protected resources.
Improves accuracy and noise reduction during active scans.
Linked Issue
Fixes: #9183