Skip to main content
Access control vulnerabilities allow attackers to act outside of their intended permissions. They are consistently ranked as the #1 web application risk by OWASP and can lead to unauthorized data access, account takeover, and full application compromise.

​
unauthenticated-resource-access

Critical

​
What it is

A resource that should require authentication is accessible without any credentials. This includes dashboards, account pages, admin panels, and API endpoints that return sensitive data.

​
Why it matters

An attacker who discovers an unprotected route can access user data, administrative functions, or sensitive application state without needing to log in at all.

​
How QAOS detects it

The agent identifies pages that appear to require authentication, then opens a fresh unauthenticated browser session and navigates directly to those pages. If the page loads normally instead of redirecting to login, the issue is confirmed.

​
Example

GET /dashboard HTTP/1.1
Host: app.example.com
# No session cookie or Authorization header

HTTP/1.1 200 OK  ← should be 401 or redirect to /login

​
How to fix

Implement server-side authentication checks on every protected route. Never rely on client-side routing alone. For APIs, require a valid session token or JWT on every endpoint that returns non-public data. Use middleware that enforces authentication by default, with explicit opt-out for public routes.

​
privilege-escalation

Critical

​
What it is

A user can perform actions or access resources that require higher privileges than they have been granted. For example, a regular user accessing admin functions, or modifying another user’s data.

​
Why it matters

Privilege escalation allows attackers to elevate their access without breaking authentication. Common attack vectors include modifying hidden form parameters, changing user IDs in API requests, or guessing admin URLs.

​
How QAOS detects it

The agent looks for admin interfaces, privileged action buttons, or forms that manipulate sensitive data. It then attempts role parameter tampering (e.g., adding ?role=admin or isAdmin=true) and tries to execute privileged actions as a regular user.

​
Examples

POST /api/users/update
{"userId": "456", "role": "admin"}   ← tampering with role field

GET /admin/delete-user?id=123        ← admin endpoint accessible to regular user

​
How to fix

Enforce authorization checks server-side for every action. Never trust client-supplied role, privilege, or user ID values. Use a centralized authorization layer (e.g., RBAC/ABAC policies) and explicitly verify that the authenticated user has permission for each operation they request.

​
access-control-method-bypass

Critical

​
What it is

An endpoint enforces access control only for specific HTTP methods (e.g., POST) but not others (e.g., GET, PUT). An attacker can bypass the check by changing the HTTP method.

​
Why it matters

Many frameworks route GET and POST to the same handler with different access logic. If the authorization check is tied to a specific method, sending the same request with a different method can bypass it entirely.

​
How QAOS detects it

The agent intercepts API requests made during normal navigation, then replays those requests using different HTTP methods to check whether the authorization check is method-specific.

​
Example

DELETE /api/admin/users/123
Authorization: Bearer regular-user-token

HTTP/1.1 200 OK  ← DELETE bypassed the POST-only auth check

​
How to fix

Apply authorization checks based on the resource and action being requested, not the HTTP method. Your server-side authorization middleware should run for all methods on protected routes.

​
forced-browsing-direct-url-access

Critical

​
What it is

An attacker directly navigates to a URL containing a predictable or guessable resource identifier to access resources that belong to other users. Also known as Insecure Direct Object Reference (IDOR).

​
Why it matters

If your application uses sequential numeric IDs or predictable UUIDs in URLs and doesn’t verify that the requesting user owns the resource, any authenticated (or unauthenticated) user can iterate through IDs to access or extract data.

​
How QAOS detects it

The agent identifies URLs containing ID parameters (e.g., /user/123, /order/456), guesses adjacent identifiers, and attempts to access those resources. It also probes predictable paths like /admin/config or /api/users/all.

​
Examples

GET /user/123/profile    ← legitimate request by user 123
GET /user/124/profile    ← user 123 accessing user 124's profile (IDOR)

GET /admin/config        ← direct URL guess to admin configuration

​
How to fix

Always verify server-side that the authenticated user has permission to access the specific resource ID requested. Use non-sequential, hard-to-guess identifiers (e.g., UUIDs v4) where possible. Implement object-level authorization checks, not just route-level authentication. 
# Check ownership before returning data
if resource.owner_id != current_user.id:
    raise HTTPException(status_code=403)