Ravindra BagaleCourses & study guides मराठी Track your progress

29. OWASP Top 10 Web Vulnerabilities

29.5 A01 Broken Access Control and IDOR

By Last updated:

In short: Broken access control is the #1 risk: a user can do or see things they should not.

Quick answer: the short, self-contained version of this lesson is the guide Secure REST APIs with OWASP API Security Top 10.

Broken access control is the #1 risk: a user can do or see things they should not. IDOR (Insecure Direct Object Reference) is the classic case – changing an ID in a URL to read someone else's data.

You see:  https://app.com/invoice?id=1001   (your invoice)
You try:  https://app.com/invoice?id=1002   (someone else's – and it shows!)

The server showed the record without checking that it belongs to you. This is horizontal escalation (Chapter 26) at the application level.

The fix – always check ownership and role on the server:

// after loading the record, confirm it belongs to the logged-in user
$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = ? AND user_id = ?");
$stmt->execute([$_GET['id'], $_SESSION['user_id']]);
if (!$row = $stmt->fetch()) { http_response_code(403); exit('Forbidden'); }

Never rely on hiding a button or a menu – enforce every permission on the server, for every request.

Ravindra Bagale's Tip

"The admin page link isn't visible to normal users, so it's safe" is the biggest misconception. An attacker doesn't need the link – they type the URL directly! Check role and ownership on the server for every request. In the Reels app, confirm on the server that one user cannot delete another user's post.

Lab

In Juice Shop, log in and try to view another user's basket by changing the id in the request (Burp). In your reels app, add an ownership check to every action (view, edit, delete) and confirm one user cannot touch another's posts.

Real incident: Denmark CPR register – a company's legitimate access abused to pull 8.8 million records (Oct 2026)

1. What happened

On Monday 5 October 2026, Denmark's Ministry of Research, Education and Digitalisation announced a serious security incident in the CPR (Det Centrale Personregister), the national civil register that holds about 11 million people (living, moved abroad and deceased). Unauthorised people misused a Danish private company's legal access to search the CPR system and got names, addresses and CPR numbers for about 8.8 million registered people. The activity happened during September; the CPR administration noticed irregular behaviour on the evening of Friday 2 October and found the scale over the weekend. People registered with name and address protection were not affected. The company's access has been stopped, the case was reported to the Danish Data Protection Agency (Datatilsynet) on 4 October, and police are investigating. Datatilsynet said the report describes a very large number of automated lookups made to identify valid CPR numbers. The authorities have not named the company or said how its access was taken over. Educational framing only.

2. How the hack happened (public reporting only – high-level)

  1. A private company had a legal, approved connection to search the CPR register (in Denmark, approved companies may look up certain details about people they already know).
  2. Unauthorised people got the ability to use that company's access (how this happened is not public yet).
  3. Because the requests came through a trusted account, the system treated them as normal company lookups.
  4. They sent a very large number of automated lookups, guessing CPR numbers to find which ones are valid – the same idea as changing id=1001 to id=1002, but done millions of times by a script.
  5. For every valid number the register returned the name and address, so over about ten days in September they built a copy covering most of the country.
  6. The CPR administration only noticed the unusual pattern on 2 October, after the lookups were done.

3. How to stop it / defend (this lesson: broken access control)

  • Check purpose, not just login: the server should only answer lookups for people that client really has a reason to see (the "belongs to you" check from the code above, applied to partners too).
  • Rate limits and quotas per client: a company that normally does a few hundred lookups a day should be blocked automatically if it suddenly does thousands per hour.
  • Block guessing of IDs: many "not found" answers in a row from one client is a sign of someone guessing numbers – slow it down, alert, and stop it.
  • Strong login for machine and partner access: short-lived keys or certificates, MFA for the people who manage them, and the ability to switch one partner off quickly.
  • Monitor in real time: send the lookup logs to the SOC (Chapter 31) and alert on volume spikes, odd hours and new source IPs – not weeks later.

4. How to take care so it won't happen again (checklist)

  • [ ] Keep a list of every outside company or system with API access to your data, with the reason and the daily volume it really needs.
  • [ ] Give each partner a hard daily limit and an alert at a lower warning level.
  • [ ] Review and re-approve partner access at least once a year; remove what is no longer used.
  • [ ] Practise the "switch off one partner" step so you can do it in minutes.
  • [ ] Warn people after a leak: scam calls and emails will now "know" their name, address and ID number – that does not make them genuine, and nobody should share passwords or OTPs.
  • [ ] India students: the same risk exists for any portal that allows Aadhaar, PAN or mobile-number lookups – ask "what if a trusted partner's key is stolen?", and report incidents to CERT-In within the required time (see Ch.34).

Source: Danish Ministry of Research, Education and Digitalisation, "Omfattende uautoriseret adgang til borgeres CPR-oplysninger", 5 October 2026; Datatilsynet, "Datatilsynet er opmærksom på sag om opslag i CPR", 5 October 2026; DR Nyheder, "Professor: 'Det største brud nogensinde mod det danske CPR-register'", October 2026; BleepingComputer, Bill Toulas, "Denmark population registry data breach affects 8.8 million people", 5 October 2026.

Check if you're safe: Password Strength Checker · Website Security Checklist

Real incident: Ukraine and Russia emergency alert apps – hacked apps sent fake nuclear and chemical warnings (Nov 2026)

1. What happened

In this lesson you learnt broken access control: if the wrong person can reach an admin action, they can make the system do something trusted. Here the trusted action was a public emergency alert.

  • Late on Sunday 1 November 2026 into Monday 2 November, both Ukraine’s Air Alert app and Russia’s Emergencies Ministry app were hit by cyberattacks hours apart.
  • Ukrainian users got false warnings of radiation, chemical threat, nuclear danger and street fighting in Kyiv and other areas. The Ukrainian Air Force quickly said there was no radiation threat and that the app had been interfered with.
  • About 2:45 a.m. Moscow time, Russia’s ministry said fake alerts went to users in 33 of 89 regions, including talk of nuclear warheads; it said attackers used a vulnerability in the app’s administrative panel.
  • Ukraine temporarily suspended the app’s push notifications; Russia isolated and then restored its app. Both sides said sirens, SMS, TV and radio still worked.
  • A group name Hitcore was mentioned around the Ukraine breach in some channels; that claim was not independently verified in the AP/PBS reporting.

2. How the hack happened (public reporting only – high-level)

  1. Each country runs a mobile app that can send emergency push alerts to citizens.
  2. Those apps have an admin / push path that can publish messages to many phones.
  3. Attackers got enough access to that path (Russia publicly blamed an admin-panel flaw) to send fake alerts.
  4. False nuclear and chemical messages went out; officials told people to ignore the app and trust other channels.
  5. The apps were paused or isolated, then restored with extra protection work.

3. How to stop it / defend (this lesson: broken access control)

Why: an alert button is a high-privilege action. If anyone outside a tiny, checked group can press it, a whole country hears a lie.

Controls you can use:

  1. Lock the admin panel off the public internet. VPN or allow-listed IPs only (Examples 1–2).
  2. Two people to send a mass alert. One drafts; another approves on a second device.
  3. Strong unique admin logins + MFA, and short session times for the push console.
  4. Watch the push API. Alert when a mass send happens at an odd hour or from a new IP (Example 3).
  5. Have a public “ignore the app” channel ready: sirens, SMS, verified social accounts, TV/radio.
  6. Rate-limit and sign alert payloads so a stolen session cannot spray unlimited messages.

Example 1: see if an admin TLS port is listening on all interfaces (your lab only).

  1. On the app server you own, run sudo ss -tlnp | grep -E ':443|:8443'
  2. Output: like LISTEN 0 128 0.0.0.0:8443 ... users:(("admin-panel",pid=441,fd=4)).
  3. What it means: 0.0.0.0:8443 is reachable on every network path. Bind it to the VPN address instead.

Example 2: check the firewall rule that allows that panel.

  1. Run sudo ufw status | head
  2. Output: like 8443/tcp ALLOW Anywhere.
  3. What it means: the whole internet may reach 8443. Change the rule to your VPN subnet only.

Example 3: spot recent push/admin calls in your own nginx log.

  1. Run grep -E 'admin|/api/push|/notify' /var/log/nginx/access.log | tail -n 5
  2. Output: like 203.0.113.9 - - [01/Nov/2026:22:47:01] "POST /api/push HTTP/1.1" 200.
  3. What it means: a mass push at an odd time is a signal to pause sending and call the second approver.

4. How to take care so it won't happen again (checklist)

  • [ ] Alert admin panels are not on the open internet.
  • [ ] Mass alerts need two people and MFA.
  • [ ] Odd-hour or new-IP mass sends wake a human.
  • [ ] Citizens have a second official channel when the app is wrong.
  • [ ] Compromised admin sessions can be killed fast.
  • [ ] Push APIs are rate-limited and reviewed after every drill.

Source: Associated Press / PBS NewsHour, Ukraine and Russia emergency app cyberattacks with fake alerts, 2 November 2026; CBS News and Straits Times same-day reporting; Russia Emergencies Ministry statements quoted in those outlets.

Ravindra Bagale's Tip

An alert button is more powerful than a password reset. Keep it off the open internet, need two people to press it, and always have sirens or SMS as plan B when the app lies.

Check if you're safe: Website Security Checklist

Real incident: CRAFTY FALCON – CERT-In warns that AI-assisted attackers are calling Indian lenders' own payment APIs to move money (Nov 2026)

1. What happened

In this lesson you learnt about A01, broken access control. It means the server does not check, on every request, whether this caller is really allowed to do this action. This real case from India shows what that costs: attackers used the victims' own payment systems to send money out.

  • CERT-In is India's national cyber security agency. Its finance team, CSIRT-Fin, looks after banks and other money firms.
  • On 4 November 2026, CERT-In issued a new warning to banks, NBFCs, digital lending apps, fintech firms, payment aggregators and crypto exchanges. It updates an earlier warning from 9 October 2026 about attackers misusing payment and disbursement APIs (the systems that send money out, for example loan payouts).
  • CERT-In gave the attacker group a name: CRAFTY FALCON. It calls it an AI-assisted money-stealing group. It uses publicly available AI attack tools, which CERT-In names as ARTEX, PentAGI, Cairn and CyberStrikeAI, so it can work at machine speed.
  • CERT-In says the threat is active and ongoing. Some firms that had already fixed things after the first warning were attacked again. Attacks were timed for holidays, weekends and nights, when fewer people watch.
  • The same day, India's cybercrime centre I4C also warned all financial firms. It said attackers first use unpatched software or bad settings to get in, and then go after the systems that send money.
  • CERT-In has not named the victim companies. News reports link the warning to a rise in unauthorised fund transfers from Indian financial firms.

2. How the hack happened (public reporting only – high-level)

  1. AI tools scan the target quickly and look for weak spots, such as old unpatched software or wrong settings.
  2. The attackers study the company's mobile or web app to learn how it talks to the payment API.
  3. Reports say they change the app's client-side code, so they can send their own requests that skip the checks the real app does.
  4. Some attackers also misuse a payment aggregator's merchant settlement API to send settlement money to a different account.
  5. They first send a tiny test payment, even ₹1, to see if the trick works.
  6. If it works, they send bigger amounts to new beneficiary accounts, often at night or on a holiday.

3. How to stop it / defend (this lesson: access control)

Why: the app on a phone is in the attacker's hands. Anything the app checks can be skipped. Only the server can decide what is allowed. So every money request must be checked on the server, every time.

Controls CERT-In and I4C point to:

  1. Check every payment on the server. Check who is calling, whether they are allowed to pay this account, and whether the amount is inside their limit. Never trust a value only because the app sent it (Example 1).
  2. Use maker-checker for money. One person or system creates a payout and a different one approves it, especially for settlement changes and new beneficiaries.
  3. Use short-lived keys with a small scope. An API key should do one job, and expire soon. CERT-In also says to replace IP allow-lists for shared third-party services with proper identity-based login.
  4. Put limits on money flow. Set daily and per-transaction limits, add a cooling-off time for new beneficiaries, and check the beneficiary's name before paying.
  5. Watch for the pattern. A ₹1 test payment to a new beneficiary, followed by large transfers, is a red flag (Example 2). Many payouts in one minute is machine speed (Example 3).
  6. Keep test systems apart. Testing and staging systems must not be able to reach live payment systems.
  7. Watch harder on holidays. CERT-In asks for 24x7 monitoring, with more staff and lower alert levels on weekends and holidays.

Example 1: make sure your own lab API refuses a payout without login.

  1. Start the practice API from this course on your own computer (never test a real company's system).
  2. Run curl -s -o /dev/null -w "%{http_code}\n" -X POST http://localhost:8080/api/payout
  3. Output: 401
  4. What it means: 401 means "not logged in", so the server refused the request. If you see 200 here, the server is doing the payout for anyone who asks. That is broken access control. Fix it before anything else.

Example 2: find tiny test payments in a payout export.

  1. Export your payout records to a CSV file with the columns time, account, beneficiary and amount.
  2. Run awk -F, '$4 <= 1 {print $1, $3, $4}' payouts.csv
  3. Output: one line for each payout of ₹1 or less, like 2026-11-01T02:14 NEW-BEN-0042 1
  4. What it means: a ₹1 payment to a brand-new beneficiary at 2 am is how this group tests a stolen path. Block that beneficiary and look at what came next.

Example 3: count payouts per minute.

  1. Use a payout log where each line starts with the time, like 2026-11-01T02:15:07.
  2. Run cut -c1-16 payouts.log | sort | uniq -c | sort -rn | head -3
  3. Output: the three busiest minutes, like 48 2026-11-01T02:15
  4. What it means: 48 payouts in one minute at 2 am is not a human. Set an alert, and a hard limit, far below that number.

4. How to take care so it won't happen again (checklist)

  • [ ] Every payment API checks login, permission and limits on the server, for every request.
  • [ ] New beneficiaries and settlement changes need a second approval (maker-checker).
  • [ ] API keys are short-lived, do one job, and are never shared between partners.
  • [ ] Daily and per-transaction limits, and a cooling-off time for new beneficiaries, are switched on.
  • [ ] I get an alert for ₹1 test payments and for many payouts in one minute.
  • [ ] Staging and test systems cannot reach live payment systems.
  • [ ] Someone is watching alerts on nights, weekends and holidays.
  • [ ] We have applied the CERT-In advisory of 9 October 2026 and its 4 November 2026 update.

Source: CERT-In / CSIRT-Fin advisory on "CRAFTY FALCON" (update to the 9 October 2026 advisory on payment and disbursement API abuse), issued 4 November 2026, as reported by PTI in The Economic Times, 4 November 2026; BW Businessworld, "Hackers Using AI To Target BFSI Sector In Escalating Cyber Campaign: CERT-In", 4 November 2026; Reuters via CNA, "India cybercrime agency warns financial firms of AI-driven cyberattacks" (I4C advisory), 4 November 2026.

Ravindra Bagale's Tip

Think of your mobile app as a form that the customer fills in. The customer can write anything on a form. Your server is the bank clerk, and the clerk must check every form, every time, even at 2 am on Diwali. If your payout system says yes to anyone who knows the right address, it is not a payout system. It is an open cash counter.

Check if you're safe: Website Security Checklist