CWE-306 is the weakness of not asking at all. The product does not perform any authentication for functionality that requires a provable user identity, or that consumes a significant amount of resources.
It is not about weak passwords or flawed tokens. It is about a door with no lock: an admin script, a management port, a legacy endpoint or a device protocol that anyone who can reach it may use. MITRE lists platforms as not language specific, cloud computing and ICS/OT.
How it happens
A few patterns account for most cases.
The forgotten route. A web app protects its main pages with a login filter, but a helper script, an old API version or a file under an includes directory sits outside the filter. In CVE-2024-11680, a file-sharing PHP product did not check whether the user was logged in for requests to PHP library files under an includes/ directory, which allowed configuration changes, code execution and other impacts.
The assumed-private channel. MITRE describes a login service on one network port that, after a successful login, opens a second port and waits for the connection without authenticating it, assuming only the authenticated party would connect. Anyone who finds the second port walks in.
The protocol that never had authentication. In CVE-2022-29951, a TCP-based protocol in a Programmable Logic Controller has no authentication. In CVE-2022-29952, a condition monitor's firmware uses a protocol that does not require authentication.
The backdoor. CVE-2022-31260 is a chain in which a digital asset management program had an undisclosed backdoor in the legacy version of a PHP script that could allow an unauthenticated user to export metadata.
The client-side only check. The login screen enforces the rule, but the server does not. An attacker skips the screen and calls the server directly.
# Vulnerable: the route does the work with no identity check
@app.route("/api/users/<uid>/export")
def export_user(uid):
return jsonify(load_user_data(uid))
# Fixed: identity required and authorization checked on the server
@app.route("/api/users/<uid>/export")
@login_required
def export_user(uid):
if current_user.id != uid and not current_user.is_admin:
abort(403)
return jsonify(load_user_data(uid))
What an attacker gains
Exposing critical functionality gives an attacker the privilege level of that functionality. MITRE says consequences depend on the context and range from reading or modifying sensitive data to full compromise through resource consumption or code execution. The listed impacts are access control bypass and gaining privileges or the identity of another party.
For industrial equipment the same gap can mean sending control commands. For a cloud storage bucket it can mean reading everything inside.
How to find it
MITRE's detection methods combine human and tool work:
- Manual analysis. Penetration testing, threat modeling and interactive tools that let a tester record and modify an active session. Manual static analysis helps evaluate whether the authentication in use is performed correctly and is not bypassed.
- Automated static analysis. Useful for spotting commonly used authentication idioms. A tool may analyze configuration files such as
.htaccessor detect the use of well-known authentication libraries. - Dynamic analysis. Web application scanners, web services scanners and database scanners give partial coverage.
- Binary or bytecode analysis when you have no source.
A simple inventory test also pays off. List every route, port and message type, then call each one with no credentials. Anything that answers with real data or performs an action needs an explanation.
How to fix it
MITRE's mitigations, in plain steps:
- Divide the software into zones. Separate anonymous, normal, privileged and administrative areas. Decide which need a proven identity, and use a centralized authentication capability.
- Protect every channel. Identify all communication channels and means of interaction, including those assumed to be reachable only by authorized parties. If a session persists across multiple connections, authentication has to cover them all.
- Duplicate client-side checks on the server. Attackers can modify values after the checks run, or alter the client to remove the checks entirely.
- Avoid home-grown authentication. Use what the framework, operating system or environment provides. Those capabilities tend to avoid weaknesses unique to authentication, support auditing, and keep authentication separate from authorization.
- If you must write custom routines, apply them to every page. Pages can be requested directly.
- Use vetted libraries or frameworks that make the weakness hard to introduce, for example OpenSSL or the ESAPI Authenticator, as MITRE suggests.
- In the cloud, require strong authentication for users who should access stored data, using the provider's controls for S3 buckets, Azure blobs and Google Cloud Storage.
Dependencies matter here too. A third party package can ship an unauthenticated admin route, and you will not find it by reading your own code. Run a free in-browser dependency scan (no login, the file stays on your machine, up to 100 dependencies) to see which of your packages carry known advisories, and use reachability analysis to learn whether your code calls the affected function.
Try it yourself
This demo walks through an API security scan, the kind of dynamic check MITRE lists for finding this weakness.
Click through it at your own pace, or open it full screen.
Quick check
Our admin panel is only reachable on the internal network. Is that authentication?
No. Network location is not identity, and it is easy to lose (see CWE-291). Require a login even for internal tools.
The front end hides the button from non-admins. Is that enough?
No. The server must enforce the rule, because a caller can request the endpoint directly.
What is the fastest check for this weakness?
List every route, port and protocol message, call each without credentials, and investigate anything that answers.
