Access and Delete 💀

How I Sneaked Into the Shop Owner’s Admin — and Deleted “Carlos”

This one felt like a heist movie — except it was a PortSwigger lab, so totally legal and zero real-world damage. Imagine a small online shop. The owner is always active, and his son Carlos runs a loud, bossy account on the site that keeps spamming sales posts. In the lab, our objective is simple (and perfectly safe): get into the admin panel and delete the user carlos. Let me tell you how the scene played out — like a little story.

The shop looks normal: a clean shopfront, product cards, checkout. Near the top of the site there’s a hidden route everyone talks about in the lab — /admin — which should be the owner’s private control room. When I tried going to /admin my browser hit a wall: a plain “access denied” page. The page looked boring. That boringness was the kind of clue a curious person can’t ignore.

The front-end was acting like a polite bouncer — “No entry, mate.” But the bouncer looked generic, like a static block page. My detective brain went: maybe the front-end is blocking the door, but the real admin room inside might still exist. In layered web architectures (CDN/proxy → front-end → back-end), sometimes the front-end blocks a path while the back-end still exposes it — especially if some routing information is passed along by headers. So I set up a little experiment in my lab tools.

Tools and characters in the scene

Me: curious tester (ethical, lab-only)
Tools: Burp Suite (Proxy & Repeater) and a browser for screenshots
Target: PortSwigger lab site (the shop)
Goal: access admin panel and delete carlos (lab-only)

1) Start intercepting

In Burp, enable Proxy → Intercept → Intercept is on.
Open the lab site in your browser. Burp will stop the outgoing HTTP request and show it in the Intercept tab.
Click the Intercept tab so you can edit the raw HTTP request before forwarding.

2) Confirm the header controls what the back-end sees

You should see a capture request.
Observe the response in your browser (or check Proxy → HTTP history): you should get a Not Found style response.
- Why: the back-end is reading X-Original-URL and returning content based on it. /invalid yields Not Found.
Edit the request in Intercept as follows:
- Change the request-line path to / (so the front-end will accept/route it).
- Add the header: X-Original-URL: /invalid
Click Forward (or Go) to send this edited request to the server.

3) Force the back-end to show the admin

Go back to Proxy → Intercept and capture another request (or use the same flow again so you can edit).
Edit the request.
Forward the edited request.
Check the browser or HTTP history — the response body should now contain the admin panel HTML.
- Why: the back-end trusted the X-Original-URL value and served the admin page even though the front-end blocks direct /admin requests.

4) Delete `carlos` — do it from Intercept

Now perform the delete action by intercepting the admin’s Delete button click (or manually craft the request in Intercept):
- If you click Delete in the admin UI while intercept is on, Burp will capture the outgoing delete request. Edit that captured request OR craft it manually like in image:
- Forward the edited request.
- Observe the response in the browser or Proxy → HTTP history — the lab should show success and carlos should be removed.
  - Why: the back-end processed /admin/delete (as indicated by the header) and acted on the query parameter username=carlos.

Backend vs Front-end — quick recap (why this works)

Front-end (proxy/router/CDN): blocks direct /admin access and shows a generic block page. It normally rewrites or sets headers to tell the back-end the original path.
Back-end (app server/framework): trusts the X-Original-URL header to determine routing. If it doesn’t re-check authentication/authorization and trusts that header from the client, a tester can set it and bypass the front-end block.
Core issue: inconsistent enforcement of access controls across layers and trusting client-controllable headers.

Conclusion

Since you worked entirely inside Intercept, the flow is: capture → edit request-line and add X-Original-URL → forward → observe response → repeat for delete. In this PortSwigger lab the back-end honored the X-Original-URL header, allowing you to view the admin panel and delete carlos. The real takeaway for production systems: never trust headers coming from unverified clients — enforce server-side authentication and authorization for all sensitive actions and strip/validate proxy headers.