FREE
Part of the AI/LLM Hacking Course — 90 Days
🎯 What You’ll Master in Day 21
⏱️ Day 21 · 3 exercises · Kali Terminal + Browser + Think Like Hacker
✅ Prerequisites
- Day 20 — LLM API Reconnaissance
— the endpoint inventory from Day 20 is the input to Day 21’s authentication testing; you need the full endpoint list before you can test auth on each one
- Day 17 — Burp Suite for LLM Testing
— removing and modifying auth headers is done in Burp Repeater using the workflow from Day 17
- Basic JWT knowledge — understanding how JSON Web Tokens are structured and how algorithm confusion attacks work
📋 LLM Authentication Bypass — Day 21 Contents
In Day 20 you built the endpoint inventory. Day 21 starts the exploitation phase with the highest-priority check: does each endpoint actually enforce authentication? Day 22 covers advanced injection chains — multi-step attacks that build context across turns to produce compliance the single-turn techniques from Days 4 and 16 can’t achieve.
Why AI Endpoint Authentication Fails More Often Than Application Auth
The core reason is timing. Most applications build authentication infrastructure during the initial architecture phase — it becomes part of the foundation. AI features come later, usually much later. By the time the AI chat endpoint is being built, the application already has working auth, working rate limiting, working session management. The developer building the AI feature assumes all of that infrastructure applies to new routes automatically. Sometimes it does. Often it doesn’t.
Three specific patterns produce the gap consistently. Separate router modules that don’t inherit middleware chains — the most common pattern I see. Proxy layers between the frontend and the AI backend that strip authentication headers before forwarding. And AI endpoints built directly against the third-party AI API rather than through the application’s backend, which means they have their own API key management and often no user authentication layer at all. Each of these requires a different test approach, but all three produce the same symptom: you remove the auth token and get a valid AI response.
Unauthenticated Access Testing
The test is simple. From the Day 20 endpoint inventory, take each AI endpoint. Open it in Burp Repeater. Remove the Authorization header, the session cookie, or whatever credential the normal request uses. Send the request. Check the response code and response body.
Three outcomes. A 401 or 403 response: authentication enforced, move on. A 200 response with an error message about missing credentials: authentication partially enforced — check whether a different authentication method works. A 200 response with valid AI output: unauthenticated AI endpoint confirmed. That third outcome is an immediate High to Critical finding before you’ve done anything else — an unauthenticated AI endpoint exposes whatever the AI can access to anyone on the internet.
⏱️ 20 minutes · Kali Linux · Python · Burp
This exercise builds a scanner that takes the Day 20 endpoint inventory as input and tests every endpoint for authentication enforcement, IDOR via user ID substitution, and rate limiting. The output is a prioritised list of authentication findings ready for manual confirmation.
nano day21_auth_scanner.py
Step 2: Build the scanner:
import requests, json, time
from datetime import datetime
# Load endpoints from Day 20 recon output
# Format: list of {“url”: “…”, “auth_token”: “…”, “user_id”: “…”}
ENDPOINTS = [
{“url”: “http://localhost:5000/api/chat”,
“auth_token”: “Bearer test_token_123”,
“user_id”: “user_001”},
]
def test_auth(endpoint):
url = endpoint[“url”]
token = endpoint.get(“auth_token”, “”)
results = {}
# Test 1: No credentials
r = requests.post(url, json={“message”:”test”}, timeout=8)
results[“no_auth_status”] = r.status_code
results[“unauth_ai_response”] = r.status_code == 200 and \
any(w in r.text.lower() for w in [“content”,”generated”,”response”,”answer”])
# Test 2: Invalid token
r2 = requests.post(url, json={“message”:”test”},
headers={“Authorization”: “Bearer invalid_token_xxx”}, timeout=8)
results[“invalid_token_status”] = r2.status_code
# Test 3: IDOR — substitute a different user ID if accepted in body
if endpoint.get(“user_id”):
r3 = requests.post(url,
json={“message”:”test”,”user_id”:”user_002″},
headers={“Authorization”: token}, timeout=8)
results[“idor_status”] = r3.status_code
results[“idor_different_context”] = “user_002” in r3.text
# Test 4: Rate limit check — 20 rapid requests
rate_hits = 0
for _ in range(20):
rr = requests.post(url, json={“message”:”ping”},
headers={“Authorization”: token}, timeout=5)
if rr.status_code == 429: rate_hits += 1
results[“rate_limited”] = rate_hits > 0
return results
Step 3: Run and report:
for ep in ENDPOINTS:
print(f”\n[{ep[‘url’]}]”)
r = test_auth(ep)
if r.get(“unauth_ai_response”):
print(” [CRITICAL] UNAUTHENTICATED AI ACCESS”)
if r.get(“invalid_token_status”) == 200:
print(” [HIGH] INVALID TOKEN ACCEPTED”)
if r.get(“idor_different_context”):
print(” [HIGH] POTENTIAL IDOR — different user context returned”)
if not r.get(“rate_limited”):
print(” [MEDIUM] NO RATE LIMITING DETECTED”)
print(f” Raw results: {r}”)
Step 4: Test against your Day 17 test endpoint:
Configure one endpoint entry pointing to your OpenAI-based test app.
Set auth_token to a valid token.
Remove the auth middleware from one route to simulate the vulnerability.
Confirm the scanner detects it.
📸 Screenshot your scanner output showing authentication test results. Share in #day21-auth-bypass on X.
IDOR at the AI Layer
IDOR in AI applications isn’t just about accessing another user’s record. It’s about accessing their entire AI context — conversation history, personalised system prompt configuration, documents uploaded to their RAG session, and any user-specific data the AI has been given access to. The impact is often higher than classic IDOR because an AI session can contain substantial personal context that the user shared over multiple conversations.
The attack surface: any parameter in the AI request that identifies the user or their session. User ID in the request body, session ID in the URL, conversation ID in the query string. Test by substituting another user’s identifier. The classic test — increment an integer ID by one — still works. For UUID-based identifiers, you need another valid identifier to substitute, which usually means registering two test accounts on the target. Use account A’s session token, substitute account B’s conversation ID, and check whether account A’s request returns account B’s conversation history.
Embedded API Key Exposure
Finding an OpenAI or Anthropic API key in frontend JavaScript is an immediate Critical finding. The key gives anyone who finds it direct API access with the application’s billing allocation, at the application’s rate limits, with no authentication required on their end. They don’t need to interact with the application at all — they take the key and call the API directly. Every API call they make gets billed to the application owner.
This happens more than it should because some AI features — particularly those implemented quickly by frontend developers — call the AI API directly from the browser rather than routing through a backend proxy. The reasoning is usually speed: calling the API directly removes a backend layer and reduces latency. The security trade-off is severe and rarely thought through at the time the decision is made.
⏱️ 20 minutes · Browser + Burp Suite · Authorised target
This exercise runs the complete Day 21 authentication test sequence against a live authorised target — covering unauthenticated access, IDOR, embedded key search, and role confusion. Use the Day 20 endpoint inventory as your starting point.
For each, capture a normal authenticated request in Burp Proxy.
Step 2: Unauthenticated access test.
Send each request to Repeater.
Remove the Authorization header.
Remove the session cookie.
Send. Record the response code and whether valid AI output is returned.
Step 3: IDOR test.
Inspect each request body and URL for user identifiers (user_id,
session_id, conversation_id, account_id).
If present: substitute a different identifier.
— If using integer IDs: increment/decrement by 1
— If using UUIDs: register a second test account and use its ID
Check whether the response contains context belonging to the other user.
Step 4: Embedded API key search.
In the target’s browser: open DevTools → Sources → find all .js files.
Search (Ctrl+F) for: sk- and api_key and OPENAI_API_KEY
Or download the main JS bundle and grep it:
curl https://target.com/static/js/main.js | grep -oP ‘sk-[A-Za-z0-9]{20,}’
Step 5: Role confusion test.
Look for any field in the AI request that might represent role or
privilege level (role, user_type, tier, plan, access_level).
Substitute “admin”, “superuser”, “internal”, “developer”.
Does the AI’s behaviour change? Does it produce content it refused before?
Step 6: Document each confirmed finding with:
— The endpoint URL and HTTP method
— The specific auth gap type (unauthenticated / IDOR / embedded key / role confusion)
— The Burp request+response as primary evidence
— CVSS base score for the specific impact
📸 Screenshot Burp showing unauthenticated AI response or IDOR evidence. Share in #day21-auth-bypass on X.
Role Confusion via System Prompt Injection
Role confusion is the AI-specific variant of privilege escalation. It occurs when the AI application includes role or permission information in the system prompt, derived from user-controlled input, and the model uses that role to determine what capabilities to grant. If an attacker can inject a high-privilege role claim into the channel that populates the system prompt’s role field, they get the capabilities that role provides — without having those privileges in the application’s actual authentication system.
The most common version: a system prompt that says “The current user has role: {role}” where {role} comes from a cookie or JWT claim. If that claim isn’t validated against the application’s actual permission system before being embedded in the system prompt, substituting “admin” for “user” in the cookie or JWT grants admin-level AI capabilities. The model behaves as if the user is an admin because the system prompt says they are.
JWT Bypass on AI Routes
AI endpoints added to existing applications are prime targets for JWT bypass testing because they’re often added after the JWT validation middleware was configured and may use a different validation path. Apply the standard JWT attack toolkit: algorithm confusion (change RS256 to HS256 and sign with the public key), signature stripping (set alg to “none” to remove signature requirement), and claim manipulation (modify user ID or role claims and check if the modified token is accepted).
The tooling is the same as any JWT test — jwt_tool, Burp JWT Editor extension — but the surface is specifically the AI endpoints from the Day 20 inventory rather than the application’s main routes. A JWT bypass that fails on the main application may succeed on an AI endpoint that uses a different validation path.
⏱️ 15 minutes · No tools needed
Authentication bypass findings are most impactful when you understand not just that the bypass exists but what it enables. This exercise chains authentication failures with the AI vulnerabilities from earlier in the course to calculate real combined impact.
/internal/ai/summarise. From Day 21 testing you confirmed:
— The endpoint accepts requests without authentication (unauth confirmed)
— The endpoint’s system prompt includes: “User role: {role_from_cookie}”
— The endpoint has a RAG pipeline connected to all company documents
— No rate limiting detected
QUESTION 1 — Unauthenticated + RAG access.
The endpoint is unauthenticated. The RAG pipeline has all company documents.
Write a specific request payload that would extract the contents of a
confidential financial report from the RAG knowledge base via this endpoint.
What OWASP LLM categories does this combined finding represent?
QUESTION 2 — Role confusion escalation.
The endpoint has a role_from_cookie field that populates the system prompt.
Design a cookie manipulation that escalates from “user” to “admin” role.
What specific AI capabilities does admin role typically unlock in
enterprise AI deployments that user role doesn’t have?
QUESTION 3 — Combined attack chain.
Chain the unauthenticated access + RAG retrieval + role confusion:
Write the step-by-step attack from zero access to maximum data extraction.
What is the CVSS for the combined chain?
QUESTION 4 — LLM10 amplification.
The endpoint has no rate limiting. What attack does this enable on top
of the existing findings, and what is the business impact calculation?
QUESTION 5 — Remediation priority order.
List the four findings in order of remediation priority.
For each: what is the fix and how long does it take to implement?
📸 Write your chain analysis and share in #day21-auth-bypass on X. Tag #day21complete
📋 LLM Authentication Bypass — Day 21 Reference Card
✅ Day 21 Complete — LLM Authentication Bypass
Unauthenticated AI endpoint testing, IDOR at the AI layer via user context substitution, embedded API key extraction from JavaScript bundles, role confusion via system prompt injection, JWT bypass on AI-specific routes, and cross-tenant context leakage in SaaS deployments. Day 22 moves into advanced prompt injection chains — multi-turn attacks that build compliance across conversation history to achieve what single-turn techniques can’t.
🧠 Day 21 Check
LLM Authentication Bypass FAQ
Why do AI endpoints often have weaker authentication?
What is IDOR in AI applications?
How do you find API keys embedded in frontend code?
What is role confusion in AI applications?
📚 Further Reading
- Day 22 — Advanced Prompt Injection Chains — Multi-turn injection attacks that build compliance across conversation history, complementing the authentication findings from Day 21.
- Day 20 — LLM API Reconnaissance — The endpoint inventory that Day 21 consumes — authentication testing runs on every endpoint discovered in recon, not just documented ones.
- Day 6 — LLM02 Sensitive Information Disclosure — What authentication bypass enables at the data layer — the credential and architecture content accessible once auth is bypassed.
- PortSwigger — JWT Attacks — Complete JWT attack methodology including algorithm confusion and signature stripping, applied to AI API routes in Day 21.
