Authentication (ATJ)

AUTHENTICATION
J

Mark heeft toegang tot bronnen of services omdat er geen authenticatievereiste is, of er werd ten onrechte aangenomen dat authenticatie zou worden uitgevoerd door een ander systeem of uitgevoerd in een eerdere actie

How to play?

The key concept for this card is missing authentication. See AT Q for inconsistent authentication and AT K for changing the executing authentication code.

Scenario: Mark’s Access Without Authentication

Imagine a situation where Mark gains access to resources or services in a system that lacks proper authentication controls. This occurs because:

  1. Absence of Authentication Requirements: Certain resources or services don’t have any authentication checks in place.
  2. Misplaced Assumptions About Authentication: The system mistakenly assumes that authentication is handled by another system or was already performed in a previous action.

Example

Mark discovers that an internal reporting tool in a corporate network doesn’t require users to authenticate themselves. This tool, designed for ease of access within the network, is mistakenly left accessible without any login procedure. Mark accesses this tool and retrieves sensitive company data. The system was assumed to be secure as it was only accessible internally, but this oversight allowed for unauthorized access without any form of identity verification.

Threat Modeling

STRIDE

This scenario maps directly to STRIDE: Spoofing.

Spoofing is about pretending to be a legitimate user or entity. Even though no credentials are provided, Mark gains access to the system without authentication, effectively being treated as a valid user. The system’s failure is that it assumes authentication is done elsewhere or not needed — this lets an attacker bypass identity verification entirely.

What can go wrong?

Such an absence of authentication exposes the system to unauthorized access, potentially leading to data breaches and exploitation of sensitive resources.

For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.

What are we going to do about it?

  1. Implement authentication requirements for all resources and services, regardless of their perceived security level.
  2. Clearly define and document authentication responsibilities to ensure no system component is left unprotected due to assumptions about other systems’ security measures.
  3. Regularly audit the entire system to identify and rectify any areas lacking proper authentication controls.
  4. For each entry point, verify that the correct degree of authentication is required and occurs. Ensure this includes:
    1. Access to remote systems.
    2. APIs.
    3. Non HTML content (e.g. files, images).
    4. Reporting.
    5. Any other 'internal' functionality.

For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.

Mappings

OWASP ASVS (v4.0): 1.4.5,4.3.1

OWASP DevGuide: SC1,A1,A2,AC1,AC2,AC3

STRIDE: Spoofing

OWASP SCP: 23,32,34

OWASP AppSensor: -

CAPEC™: 115

SAFECode™: 14,28

ASVS (4.0.3) Cheat Sheet Series Index

Data tampering

Privilege escalation

Social engineering attack

OWASP Cornucopia

OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams identify security requirements in Agile, conventional and formal development processes. It is language, platform and technology-agnostic, and is free to use. OWASP Cornucopia is licensed under the Creative Commons Attribution-ShareAlike 4.0 license, so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar licence to this one.

© 2012-2025 OWASP Foundation. The Open Worldwide Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software.