CSRF, IDOR and Security Headers
Three Everyday Web Weaknesses
You have seen injection attacks. This lesson covers three more that appear constantly in bug bounty reports and penetration tests: CSRF, IDOR and missing security headers.
Legal note: Only test applications you own or have written permission to test, such as the lab below, DVWA or TryHackMe.
CSRF: Cross-Site Request Forgery
Browsers automatically attach your cookies to every request to a site, even when the request was triggered by a different site. CSRF abuses that.
How the attack works
- You log in to your bank. Your browser stores a session cookie.
- In another tab you visit a malicious page ("You won a free phone!").
- That page contains a hidden form that submits a transfer to your bank.
- Your browser sends the request with your cookie. The bank sees a valid session and approves it.
You never clicked "transfer". The attacker never saw your password or cookie. They only needed you to be logged in and to load their page. CSRF targets state-changing actions: transfers, password or email changes, settings.
Defences
| Defence | How it works |
|---|---|
| CSRF token | A random value in the form that the server checks. The attacker's page cannot read it |
| SameSite cookies | SameSite=Lax or Strict stops the browser sending the cookie on cross-site requests. Modern browsers default to Lax |
| Origin / Referer checks | Reject requests that do not come from your own site |
| Re-authentication or OTP | For sensitive actions such as new beneficiaries. Nigerian banks use OTPs and transaction PINs for exactly this reason |
Never change state with a GET request, because a simple image tag could trigger it.
IDOR: Insecure Direct Object Reference
IDOR is a form of broken access control. The app uses an identifier from the request (an ID, account number or filename) without checking that the user owns it.
GET /statement?account=1001 -> your statement
GET /statement?account=1002 -> someone else's statement (if not checked)
Attackers simply change the number, or write a script that loops through thousands. IDOR has caused many large data exposures worldwide. Examples include customer records and invoices exposed just by incrementing an ID.
Defences: check ownership on the server for every request. Use unpredictable IDs (UUIDs) as an extra layer, but never as the only one. Test your own app by logging in as two users and trying one user's IDs from the other's session.
Security Headers
Servers can send extra HTTP response headers that switch on browser protections. They cost almost nothing and stop whole classes of attack.
| Header | What it does |
|---|---|
| Strict-Transport-Security (HSTS) | Forces HTTPS, blocking downgrade and many MitM attacks |
| Content-Security-Policy (CSP) | Limits where scripts can load from, and is a strong second layer against XSS |
X-Frame-Options or CSP frame-ancestors | Stops your page being framed, which prevents clickjacking |
| X-Content-Type-Options: nosniff | Stops browsers guessing file types |
| Referrer-Policy | Limits what URL data is sent to other sites |
| Set-Cookie: HttpOnly; Secure; SameSite | Protects session cookies from scripts, plain HTTP and cross-site use |
Check a site with curl -I https://example.com (you used this in the Linux module) or free tools such as securityheaders.com. Also hide version details such as Server: Apache/2.2.8.
A Nigerian and Global Example
A Lagos fintech's web dashboard let staff view customer statements by account number. A tester logged in as a low-level user and changed the number in the URL. Thousands of other customers' statements loaded. This was IDOR, and it is the type of finding that regulators and customers take very seriously. The fix was a single server-side ownership check. Around the world, from London to Nairobi, the same mistake appears whenever developers trust the ID in the URL.
Try It in the Lab
Use the lab on the right.
Part 1: CSRF
- With all defences off, press Claim prize. Watch NGN 250,000 leave Ada's account.
- Press Reset, turn on SameSite, and try again. Read what the bank saw.
- Try each defence alone, then all together. Which ones stop the attack? Why can the attacker not defeat the CSRF token?
Part 2: IDOR
- Load account 1001 (yours), then change it to 1002 and press Load.
- Turn on Server checks ownership and repeat.
Try it yourself
Key Takeaways
- CSRF forges a state-changing request using the victim's automatically attached cookies. Use CSRF tokens, SameSite cookies, Origin checks and OTPs for sensitive actions.
- Never change state with GET requests, and require re-authentication for high-risk actions such as adding a new beneficiary.
- IDOR happens when the server trusts an ID in the request without checking ownership. Always enforce access control on the server.
- Security headers (HSTS, CSP, X-Frame-Options, nosniff, Referrer-Policy) and cookie flags (HttpOnly, Secure, SameSite) add cheap, strong protection.
- Test with two accounts, check headers with curl -I, and only test systems you own or are authorised to test.
Quick Quiz
1.Why does a CSRF attack work even though the attacker never sees the victim's password or cookie?
2.A user changes /statement?account=1001 to account=1002 and sees another customer's data. Which vulnerability is this, and what is the fix?
3.Which header tells the browser to always use HTTPS for your site and helps prevent downgrade attacks?
Ready to go further?
CareerEx gives you structured 12-week training, live classes every Saturday and Sunday, real tutor feedback, and a certificate. Join the next cohort.
Join CareerEx