Sensitive Parameter on Unauthenticated Endpoint

ID

sensitive_param_unauthenticated

Severity

high

Remediation Complexity

medium

Remediation Risk

high

Remediation Effort

medium

Family

API2:2023 - Broken Authentication

CWE

CWE-359, CWE-522

Resource

data_exposure

Language

any

Description

Fires when an endpoint accepts a parameter or request-body field whose name or schema is classified PII / PCI / PHI / credential / crypto by the sensitivity classifier, and the endpoint has no authentication requirement.

Distinct from unauthenticated_endpoint: that detector fires on the route alone; this one fires only when sensitive input is also visible. Composite finding — endpoint shape + parameter sensitivity.

Rationale

An unauthenticated endpoint that accepts PII / PCI / PHI / credentials lets any caller on the network submit that data without an identity bound to the request. Two distinct risks:

  • Inbound — the caller’s data is not tied to a user identity, so the audit trail is broken (GDPR Article 32, PCI-DSS 6.4.3). A credential-stuffing attempt, a "forgot password" flow that returns hints, or a POST /user-by-email lookup all leak information about your user base.

  • Outbound — sensitive data flowing through an unauthenticated endpoint typically also leaks back in the response (account-existence oracles, identity confirmation by side-channel timing, etc.), even when the body looks generic.

Combined with the lack of rate limiting that usually accompanies unauthenticated routes, the surface is trivially scriptable.

Remediation

Either:

  • Add an authentication requirement to the endpoint using the framework’s standard mechanism (@PreAuthorize / [Authorize] / authentication middleware) — see unauthenticated_endpoint for per-framework guidance.

  • Confirm the parameter genuinely is not sensitive in your context. The sensitivity classifier infers from name / type / annotations; over-tagging is real. Mark it via per-project configuration (sensitivityClassifier.ignore) so this detector stops firing for it.

Avoid third options — masking the parameter, removing it from the response, or relying on TLS for confidentiality. None of those address the broken audit trail.

Configuration

This detector does not require specific configuration. The sensitivity classifier itself (which decides which parameters count as sensitive) is configurable globally — see the API Security scanner configuration reference.

References