API Security Meets Threat Intelligence: Why Defending Endpoints Without Outside Visibility Is Half a Job

If you ask ten security engineers where the next breach is going to come from, at least six of them will say the same thing: an API. Not a phishing campaign, not a zero day, not a disgruntled employee. An API endpoint that somebody built in a hurry three years ago, forgot to authenticate properly, and never added to the inventory.

The numbers back this up. API traffic now makes up the majority of all web traffic. Almost every mobile app, every single page application, every integration between two SaaS products talks over APIs. And attackers have noticed. T-Mobile, Optus, Twitter, Peloton, Experian, Venmo, and a long list of smaller names all got hit through API abuse, not through classical network intrusion.

What most of those breached organizations had in common is not that their code was uniquely bad. It is that they were defending their APIs with only an inside view. They knew which endpoints they had shipped. They did not know which endpoints attackers had already found, which credentials for their services were already circulating on Telegram, or which of their subdomains had quietly been exposed by a forgotten CI job. That gap between the inside view and the outside view is where API security and threat intelligence meet, and it is the single highest leverage investment most teams are not making. This post walks through what breaks in production APIs, how attackers actually work, and how threat intelligence turns API defense from a passive exercise into a proactive one.

The Two Views of Your API Surface

Every security team has an inside view of their APIs. It is the inventory in their API gateway, the list of services in their architecture diagram, the routes defined in their code. This is the view that tells you what you meant to expose. The outside view is what attackers see. It is the full set of endpoints reachable from the public internet, including the staging environment someone spun up for a demo and never shut down, the v1 API that was supposed to be decommissioned two years ago, the debug endpoint that is still technically live on a subdomain nobody remembers, and the third party integration that is hosted under your domain but owned by a vendor.

These two views almost never match. Threat intelligence is what closes the gap. Done properly, it tells you which of your assets appear in certificate transparency logs that you did not register, which of your subdomains are answering on ports you did not intend, which of your API tokens have been committed to a public GitHub repository, and which of your employee credentials are already sitting in a stealer log waiting to be replayed against your authentication endpoints. If your API security program relies only on the inside view, you are defending a map of a city while the attacker is walking the actual streets.

The OWASP API Top 10, in Plain English

Before we get into how intelligence plays into defense, a shared vocabulary helps. The OWASP API Security Top 10 is the closest thing the industry has to a common reference for what breaks. The short version:

• Broken Object Level Authorization (BOLA): the endpoint lets user A access user B's data by swapping an ID in the URL or body.
• Broken Authentication: weak tokens, missing rate limits on login, JWT misconfigurations, or password reset flows that leak information.
• Broken Object Property Level Authorization: the user can access the object but should not see every field on it, and the API returns every field anyway.
• Unrestricted Resource Consumption: no rate limits, no pagination limits, no cost control. An attacker can exhaust the service or your cloud bill.
• Broken Function Level Authorization: regular users can hit admin endpoints because the check is missing or done only on the frontend.
• Unrestricted Access to Sensitive Business Flows: legitimate flows like account creation or ticket purchase abused at scale because the logic was never rate limited or monitored.
• Server Side Request Forgery (SSRF): the API accepts a URL as input and fetches it server side, letting attackers pivot into internal networks and cloud metadata services.
• Security Misconfiguration: debug endpoints left on in production, verbose errors, permissive CORS, default credentials, missing security headers.
• Improper Inventory Management: deprecated v1 endpoints still running, staging APIs exposed to the internet, undocumented endpoints discovered only when someone exploits them.
• Unsafe Consumption of APIs: your service trusts a third party API and forwards its responses without validation, inheriting any compromise of that upstream.

Here is the useful observation once you have this list in front of you: at least half of these categories can be partially discovered from the outside, before an attacker exploits them. Improper Inventory Management is literally a threat intelligence problem. Security Misconfiguration shows up in external scans. Broken Authentication is often first noticed when credentials for your endpoints start appearing in credential markets. Unsafe Consumption of APIs becomes visible when your third party providers get breached and you hear about it in threat feeds. An API security program that only reads code and only runs internal scans will catch some of the list. One that pairs internal testing with external threat intelligence will catch far more, and catch it earlier.

The Shadow API Problem Is a Visibility Problem

• Shadow APIs: endpoints built by developers that were never documented, never added to the API gateway, and never got a security review. They work. They receive traffic. Nobody owns them.
• Zombie APIs: old versions that were replaced but never turned off. Usually missing the authentication improvements of the new version, still accessible, still connected to the database.
• Third party APIs: endpoints exposed by SaaS tools that integrate with your stack, often under a subdomain of your main domain, and often invisible to your internal inventory.

Attackers find these through exactly the same techniques threat intelligence platforms use. They pull your certificate transparency logs, enumerate your subdomains, scrape your mobile app for hardcoded URLs, search GitHub for your organization name plus keywords like internal, staging, api, or key. By the time they attack, they often have a more complete inventory of your attack surface than you do.

The defense is to run the same playbook against yourself, continuously, and fix whatever your tools find before somebody else does. This is the core value of external attack surface management, and it is where threat intelligence stops being abstract and starts removing live risks from your environment week after week.

How Attacks Actually Unfold, and Where Intelligence Enters

A real API attack rarely looks like a movie. It looks like boredom and patience, and it almost always begins outside your environment. Stage one is reconnaissance. The attacker pulls your certificate transparency records, enumerates subdomains, checks GitHub for leaked keys or internal references, looks at your mobile app for hardcoded URLs, and checks underground markets to see whether credentials for your services are already for sale. At this stage you have no logs to look at, because nothing has touched your servers yet. The only way to know this is happening is to watch the same sources the attacker is watching and see what shows up about you.

Stage two is probing. The attacker signs up for a normal account, uses the product for an hour with a proxy running, and maps every endpoint. They change their user ID to somebody else's. They try the admin endpoint with their regular JWT. They send a PUT where the API expects POST. They pass their own email in a password reset request to see exactly what information the response leaks. At this stage, your own logs finally have something, but only if you are watching for iteration patterns and authorization anomalies rather than only for failed authentication.

Stage three is exploitation at scale. The famous breaches are rarely one request. They are hundreds of thousands of requests iterating through ID ranges, harvesting one record at a time. This is where rate limiting matters, where behavioral monitoring matters, and where your security team either catches the attack within hours or reads about it in the news six weeks later.

Threat intelligence shifts your earliest warning from stage three to stage one. When a leaked employee credential for your VPN appears in a stealer log, you can rotate it before anyone tries it. When a new subdomain pointing to a test API gets registered, you can shut it down before it gets scanned. When your company is mentioned on a dark web forum in the context of an access broker offering credentials, you can investigate before the access broker sells to a ransomware affiliate. None of this is possible from inside your firewall. All of it is possible with continuous external monitoring.

Authentication Is Not Authorization, and Neither Is Reputation

Every endpoint that returns data tied to a specific resource needs to check, at the database or service layer, that the authenticated user owns or has access to that specific resource. Authentication answers who is this request from. Authorization answers is this request allowed to do what it is asking to do. A valid JWT proves identity. It does not prove the user is allowed to read order number 48392.

Threat intelligence adds a third question that most systems never ask: should this identity be trusted at all right now. A JWT is valid. The user is authenticated. Authorization is correctly enforced. The request is technically allowed. But the user account is currently being advertised on a dark web channel as a compromised access, the request is coming from an IP range that showed up in a stealer log an hour ago, and the user agent matches a known credential stuffing toolkit. Each signal individually is thin. Together they are a warning you cannot afford to ignore.

This is why modern API defense feeds threat intelligence into runtime decisions. A request with a clean reputation goes through normally. A request from a known malicious IP gets challenged, rate limited harder, or blocked. A request using credentials that appear in a recent breach dump triggers a forced reauthentication. This is not paranoia, it is pattern matching against known bad, and it is exactly what attackers try to evade by rotating infrastructure, which is exactly why your intelligence has to be fresh.

Secrets, Tokens, and the GitHub Problem

A huge share of API compromises never touch the API itself. They start with a leaked credential. A developer commits an AWS key to a public GitHub repository for five minutes before realizing and force pushing over it. An API token gets pasted into a Slack channel that later gets exported. A mobile app ships with a hardcoded third party key. A customer support agent copies a database connection string into a ticket. These things happen constantly in every organization above a certain size.

Attackers know this. There are automated bots that watch GitHub's public commit stream in real time and test any string that looks like a credential within seconds of it being pushed. The window between commit and exploitation is often measured in minutes. This is the cleanest example of threat intelligence as a preventive control. If you are monitoring public code repositories, paste sites, and underground channels for your own tokens, secrets, and domain mentions, you find leaks in the same minutes the attackers do. You rotate before exploitation. Without that monitoring, you find out when your cloud bill spikes from crypto mining on your leaked key, or when your database shows unexpected read activity from a new country.

The broader version of this principle is that every credential leak is an API security incident waiting to happen. Stealer logs containing employee browser sessions, pastebin entries containing API tokens, and underground marketplace listings offering access to your infrastructure all feed the same attack. Treat the intelligence feed as part of your API defense, not as a separate security function.

Rate Limiting Is Not Enough Without Context

Every public API needs rate limits. This sounds obvious. It is not applied obviously. The common mistake is rate limiting only the login endpoint, because that is where you imagine attacks happening. Attackers do not only attack your login endpoint. They attack your search endpoint with ten thousand queries per minute to scrape your product catalog. They attack your password reset endpoint to enumerate which emails are registered. They attack your coupon code endpoint to brute force working codes. They attack your GraphQL endpoint with deeply nested queries to exhaust your database.

Rate limiting should be layered. A global cap per IP. A per user cap based on authenticated identity. A per endpoint cap that reflects the cost of that endpoint. And for sensitive flows, a per action cap that measures business logic: three password resets per hour per account, ten failed logins before a cool down, a hundred reads per minute before a soft throttle.

What pure rate limiting cannot do is distinguish between a chatty legitimate integration and a quiet attacker. That is where threat intelligence turns a blunt instrument into a precise one. A request from an IP with clean reputation and a known corporate ASN gets the generous limit. A request from a residential proxy network that is tagged in threat feeds as being used by credential stuffing campaigns gets the restrictive limit, even if the specific IP has not hit your system before. The bad traffic pays a tax. The good traffic does not feel it. That is the goal.

A user who logs in once a day for a year and then suddenly fetches every object they have access to in ten minutes is doing something worth looking at, even if every individual request is within the limits. Cross referencing that user's session against recent stealer log activity, recent breach data, and geolocation anomalies turns a weak signal into a decision.

How Threat Intelligence Actually Plugs Into API Defense

There is a difference between buying a threat intelligence feed and actually using threat intelligence. A feed that sits in a dashboard no one opens is a line item. Intelligence only matters when it reaches the places that make decisions. For API defense, those places are roughly five:

1. Asset discovery. External attack surface intelligence continuously finds your exposed endpoints, forgotten subdomains, expired certificates, and misconfigured services, and feeds them back into your inventory so the inside view matches reality.
2. Credential exposure. Leaked secrets, stolen employee credentials, and stealer log data tied to your domains flow into your identity platform for forced rotation and session invalidation before exploitation.
3. Runtime reputation. IP, ASN, and device reputation from live threat feeds enrich each request at the gateway or WAF layer, letting rate limits and authorization decisions factor in known bad sources.
4. Brand and adversary context. Mentions of your organization, executives, or products on underground forums and dark web markets give early warning that your specific brand is being targeted, which shapes how aggressively to tune other controls.
5. Incident response. When something does go wrong, intelligence provides the context to know which actor profile fits, which TTPs to expect next, and which other parts of your estate they are likely to touch.

Vendors in this space split along those five jobs. No single tool does all of them equally well, and the right stack depends on where your biggest gaps are.

• Cypho combines external attack surface management, threat intelligence, data leak monitoring, and digital brand protection in one platform. Continuous asset scanning identifies exposed APIs, unknown subdomains, expired SSL certificates, misconfigurations, and exploitable ports. The data leak and dark web monitoring side detects leaked employee credentials, API tokens, and secrets in public repositories and code sharing platforms, correlates them against your domains, and produces actionable alerts with context rather than raw data. For teams that want the asset discovery, credential exposure, and brand context pieces of the stack covered in a single console, it fits neatly.
• Hudson Rock focuses specifically on infostealer intelligence, with strong coverage of employee and customer credentials stolen from infected machines, often the first step in API abuse chains.
• Flare covers dark web, Telegram, and stealer log monitoring with a focus on ease of use for mid-size security teams.
• SpyCloud has one of the largest recaptured data sets and a strong focus on account takeover prevention, feeding directly into identity and runtime decisions.
• Censys and Shodan are the classic internet wide scanners for attack surface visibility at the network and service level.
• GitGuardian and TruffleHog specialize in detecting leaked secrets in public code repositories, which is the single most common entry point into API abuse.
• API specific vendors like Salt Security, Noname, 42Crunch, and Wallarm sit in the traffic path and focus on API inventory and runtime behavior rather than external intelligence, and are complementary to the platforms above rather than replacements for them.

The teams getting this right tend to combine one external intelligence and exposure platform with one API runtime platform, and make sure the signals from the first one actually reach the decision points in the second.

A Realistic API Security Checklist, Intelligence Informed

No list replaces engineering judgment, but if you want somewhere to start, this is the short version.

• Maintain a live inventory of every API, and cross check it continuously against an external view of your perimeter so shadow and zombie endpoints surface automatically.
• Kill deprecated versions on a schedule, and subscribe to alerts when retired endpoints start answering again.
• Enforce authorization at the data layer, not at the route layer. Make forgetting a check harder than remembering one.
• Use short lived tokens. Rotate long lived credentials automatically, and automatically when leaked credentials matching your domains appear in external feeds.
• Apply layered rate limits, enriched with IP and ASN reputation so known bad traffic pays a higher cost than clean traffic.
• Log every authentication and authorization decision, and correlate with threat intelligence at query time to distinguish anomalies from noise.
• Validate input types and sizes strictly. Reject unexpected fields instead of ignoring them.
• Do not return more data than the client actually needs. Excessive data exposure is a breach waiting to be aggregated.
• Run secret scanning continuously across your code, your collaboration tools, and the open internet, not just at release time.
• Monitor external mentions of your brand, domains, and executives on underground forums so targeted campaigns hit you with warning, not surprise.
• Include API abuse scenarios and intelligence driven scenarios in your threat modeling, not only generic web top 10.
• Test APIs with the same seriousness you test the frontend, and retest whenever intelligence indicates a new campaign is targeting your sector.

Conclusion

API security is less about exotic vulnerabilities and more about consistent fundamentals applied at scale, with one critical addition: you cannot defend what you cannot see, and most of what you cannot see lives outside your own environment.

The organizations that get breached are rarely the ones missing a cutting edge defense. They are the ones who lost track of how many endpoints they run, trusted authentication to cover authorization, rate limited only the obvious routes, and found out about their exposed tokens or stolen sessions from an attacker rather than a monitoring alert.

The organizations that stay out of next year's breach reports pair a disciplined internal API program with continuous external threat intelligence. They watch their attack surface the way attackers do. They treat every leaked credential as an API incident. They enrich their runtime decisions with reputation, and they assume that the gap between the inside view and the outside view is where every real breach starts.

Close that gap and you close most of the attack paths that matter. Leave it open and everything else you do is a partial fix.

Related reading from Cypho:

• What Are Stealer Logs? How Your Passwords Get Stolen & How to Stay Safe — Learn what stealer logs are, how infostealer malware steals passwords, cookies, and browser data, and how you can protect yourself from cyber threats.
• Artificial Intelligence in Cybersecurity — Explore how artificial intelligence enables smarter threat detection, reduces false positives, and powers the next generation of intelligent defense.