In June 2026, ServiceNow disclosed that a customer-facing API endpoint had been shipped with authentication switched off, letting anyone query internal tables on hosted customer instances without a password. It wasn’t an isolated case. In 2025, a deprecated Stripe payment endpoint, still connected to live systems, let attackers validate stolen card numbers for months before anyone noticed.
Different companies, different years, same root cause: an API endpoint that didn’t check who was asking, or told them more than it should have. None of these attacks touched the login page or the UI sitting on top of it, and both looked fine throughout. They went straight at the API behind it, the layer that actually decides what data comes back, and that is the layer a UI review never tests.
Curious if your APIs face a similar risk? The six checks below take about fifteen minutes combined, and cover:
- Endpoint mapping (what is exposed beyond your documented API)
- Authentication (whether a login is actually enforced)
- Object-level access (whether an ID swap hands over someone else’s data)
- Data exposure (what your API responses reveal that your screen doesn’t)
- Admin hygiene (who still has access, and whether they should)
- Rate limits (whether anything stops a script from hammering an endpoint)
Map every API endpoint your app actually calls
Open your app in a browser, open developer tools, go to the Network tab, and click around. Every call your front end makes to /api/… is a real endpoint, whether or not it made it into your API documentation. Do the same on your mobile app with a proxy tool if you have one.
The endpoints that get forgotten are rarely the ones in the official spec. Some of the usual culprits:
- A feature a contractor shipped, then nobody removed
- An internal admin call left reachable from the public internet
- A v1 route nobody deleted after v2 launched
Attackers build this same map before touching anything else, usually with automated crawlers that are faster at it than any human. If your own list of “endpoints we have” is shorter than what the Network tab just showed you, that gap is where incidents start. It is the same gap that let attackers quietly validate stolen credit cards against a deprecated Stripe endpoint for months in 2025: the endpoint was old, but it was still very much alive.
You might assume a small, obscure API isn’t worth a stranger’s time. Automated scanners don’t rank targets by size. They rank by what is easy, and an endpoint nobody’s watching is about as easy as it gets.
Call an endpoint with nothing in your pocket
Pick an endpoint that should require login. Open an incognito window, or strip the Authorization header with a tool like curl, and call it directly:
curl -i https://yourapp.com/api/v1/users
A 401 or 403 means the endpoint is actually checking credentials. A 200 with real data in the response means it isn’t, no matter what your login page implies. This is the single most common way APIs get emptied out: an endpoint that never checked for a credential in the first place.
Test your other sensitive routes the same way too, not just the obvious one. Teams often lock down the main endpoint and forget the quieter one built right next to it, like a CSV export or a “look up by email” route, that never got the same authentication check. It is also the exact gap from the ServiceNow story above: the endpoint had a real function; someone had just left it configured to skip the login check and never turned that back on.
Change the ID and see whose data shows up
Log in normally, find a URL or API call with a numeric or sequential ID in it, something like /api/orders/4471 or /api/users/108, and change the number to something adjacent, like 4470 or 109.
If someone else’s order, profile, or invoice loads, you have just run what is called an object-level authorization check and found the same gap attackers look for once they hold any valid account of their own. It is one of the most common security vulnerabilities in APIs because it is invisible from the outside: the endpoint works perfectly for the person it was built for, and nobody notices it also works for everyone else until an ID gets changed. It is the same vulnerability that exposed 64 million McDonald’s job applications: an applicant ID incremented in the URL, and the API never checked whether the account asking actually owned that record.
Read every field the API actually returns
Your app’s screen might show a customer’s name and order status. The API call behind that screen might return their full address, internal account ID, email, device fingerprint, or a password hash sitting quietly in a field your front end never renders.
Open the raw response in your Network tab and read every field it contains. Data that reaches the browser is data an attacker can read directly with basic tools, regardless of what your interface displays. This is how a breach exposes far more than the app appeared to hold: the interface was fine; the API underneath was handing out the rest of the file. It is exactly what happened in the Intel API breach: the API sent back a fully unfiltered object, including internal metadata and role permissions the interface was never built to display, and a researcher walked away with a nearly 1GB file of employee data.
Look for the accounts and panels nobody’s watching
Ask this directly: who currently holds admin or elevated access to your systems, and could you name every one of them right now?
In most organizations, the honest answer includes a vendor who finished a project eight months ago, a former employee whose account was disabled but never removed from the admin group, and at least one shared login nobody quite owns.
None of this shows up in a code scan. It shows up when someone pulls the actual user list and checks it against current staff and active contracts. This is consistently how attackers get in without breaking anything: they use a door left open by accident. It is the other half of the McDonald’s story: the way in wasn’t just the ID that could be incremented, it was a test admin account nobody had disabled in years, still sitting on the password “123456.”
While you are there, check for admin panels, staging environments, or test endpoints, things like /admin, /debug, /swagger, or a subdomain like test.yourapp.com, that are reachable from the public internet but were only ever meant for internal use.
Hit an endpoint fast and see what stops it
Send the same request to a login, search, or token endpoint fifty times in a row within a few seconds, using a simple script or a tool like Apache Bench. Most API traffic is machine to machine, so the control that matters here is rate limiting: how many requests a given IP, key, or token gets to make in a window before the API pushes back.
A researcher proved exactly why this matters against Volkswagen’s connected car app in 2025: the one-time code endpoint used to register a vehicle had no rate limit, so a script tried all ten thousand four-digit combinations and let him claim someone else’s car.
If all fifty requests come back 200 with no throttling and no 429 anywhere in the response codes, there is nothing between a single bad guess and ten thousand of them, run by a script in under a minute. A 429 showing up here means the control is doing its job. We have written about how to read 429 responses and tell routine throttling from an active attack, and about how rate limiting works end to end if you are setting limits for the first time.
What this check won’t catch
These checks catch the mistakes that show up fast and get exploited fast: open endpoints, missing checks on IDs, forgotten admin accounts, no rate limits. That covers a large share of how real incidents start, so the fifteen minutes are worth it.
It won’t catch a business-logic vulnerability buried three steps into a checkout flow, a chained exploit that only works when two small vulnerabilities combine, or a new API your team ships tomorrow that nobody re-checks by hand. And once this list is clean, it stays clean only until someone adds a new endpoint, which in most engineering teams happens within days.
Where AppTrana fits
This self-check is a good afternoon’s work. Keeping it accurate every week, across every API your teams ship, is what AppTrana does automatically.
API Discovery
Maps every endpoint your app actually calls, including the shadow and forgotten ones this checklist relies on a human to notice, and keeps that map current as new routes go live.
AI-powered scanning
Backed by certified AI pentesters for business-logic vulnerabilities, checks continuously for broken authentication and broken object-level authorization against the OWASP API Top 10.
Block mode from day zero
Stops an unauthenticated call to a sensitive endpoint at the edge before it reaches your application. There is no learning-mode window where the API sits exposed while the system tunes itself.
SwyftComply
Turns a finding, like an open admin route or a missing auth check, into a virtual patch at the edge autonomously and gives an SLA-backed remediation report. The fix ships before the next sprint starts.
24×7 managed team
Handles the ongoing part: watching for the endpoint that shipped last night, the access pattern that looks like enumeration, the admin account that should have been disabled months ago.
The checks above cost nothing and are worth running today. They won’t run themselves again next week, on the API your team is about to ship. That’s the part worth handing to something like AppTrana API Security that is built to watch continuously.
Start a free trial of AppTrana and find out what it catches on your APIs before someone else does. Start Free Trial → No credit card required.
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.