DAST API scanner: Honor OpenAPI security specifications for mixed public/private endpoint APIs

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

DAST API scanner now respects OpenAPI security specifications to correctly identify public endpoints and skip authentication token validation tests, reducing false positive findings while maintaining comprehensive security testing coverage.

Problem to solve

Currently, the GitLab DAST API scanner reports false positive authentication bypass vulnerabilities on public endpoints that are intentionally designed to not require authentication. Even when developers properly mark endpoints as public using the OpenAPI "security": [] specification, the scanner still performs authentication token validation tests and flags these endpoints as High severity vulnerabilities.

This creates several issues:

  • False positive noise: Security teams must manually dismiss legitimate public endpoints as false positives
  • Reduced scanner effectiveness: Teams may exclude entire public endpoints from scanning to avoid false positives, missing other potential vulnerabilities
  • Workflow inefficiency: Developers cannot rely on automated security scanning results and must perform manual triage

Proposal

Enhance the DAST API scanner to parse and respect OpenAPI security specifications:

  1. Parse OpenAPI security directives: When the scanner encounters "security": [] at the operation or path level, recognize this as an intentionally public endpoint
  2. Selective test execution: Skip authentication-related tests (like token validation) for endpoints marked as public while continuing to execute all other security tests
  3. Maintain comprehensive coverage: Ensure public endpoints are still tested for other vulnerabilities (injection attacks, data validation, etc.)
  4. Clear reporting: In scan results, distinguish between endpoints that failed authentication checks versus those that were intentionally excluded due to public specification

Technical implementation considerations:

  • Support "security": [] at both operation level and path level in OpenAPI specs
  • Maintain backward compatibility with existing scanning behavior
  • Provide clear logging/reporting when authentication tests are skipped due to security specifications

Intended users

  • [Amy (Application Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#amy-application-security-engineer) - Needs accurate vulnerability reports without false positives
  • [Sasha (Software Developer)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer) - Wants to properly document API security requirements and have them respected by tooling
  • [Simone (Software Engineer in Test)](https://handbook.gitlab.com/handbook/product/personas/#simone-software-engineer-in-test) - Requires reliable automated security testing that doesn't require manual intervention for known-good configurations

Feature Usage Metrics

  • Number of DAST API scans that process OpenAPI specs with mixed public/private endpoints
  • Reduction in manually dismissed false positive findings related to authentication bypass
  • Percentage of scans where "security": [] directives are detected and processed
  • User feedback on false positive reduction in vulnerability reports

Does this feature require an audit event?

No, this feature enhances existing scanning behavior and does not require audit events.

Edited by 🤖 GitLab Bot 🤖