API Security Executive Briefing for Boards

Most of the organisation's data and transactions now move through APIs, and an API that checks who is calling but not what they may see can hand an attacker millions of customer records through requests that look completely normal. This briefing is for directors, chief executives, audit and risk committee members and CISOs who need to oversee API risk without becoming API engineers. It explains why API failures are different from classic hacking, which questions expose weak programmes, what good looks like and where the first money should go. The technical depth sits in the API Security Guide and the individual OWASP API Top 10 guides linked below; this page stays at the level a board needs to challenge management.

The risk in one paragraph

An API (application programming interface) is the door through which mobile apps, partner systems, websites, internal services and now AI agents ask the business for data or ask it to act. A typical organisation runs hundreds or thousands of them, many built by different teams, some inherited through acquisitions and some forgotten. Attackers favour APIs for three reasons: they return clean, structured data in bulk, they are designed to be called by software so automated abuse blends in, and their most common flaw is a missing business rule rather than a software bug a scanner can find. The OWASP API Security Top 10 2023 lists Broken Object Level Authorization as the number one risk: the API confirms the caller is logged in but never checks that the record they asked for belongs to them, so changing one number in a request returns someone else's account. The damage an API failure can do is set by three things the board can influence: whether the organisation knows every API it exposes, whether each one enforces who may see what, and whether anyone would notice a valid account pulling far more data than any customer ever would.

Why this is a board-level issue now

A single API can expose a whole customer base. T-Mobile disclosed in a January 2023 SEC filing that a bad actor had abused one API without authorisation from about 25 November 2022, obtaining data on approximately 37 million current customer accounts, including names, billing addresses, email addresses, phone numbers and dates of birth. The abuse ran for about six weeks before it was detected on 5 January 2023. See the T-Mobile API breach analysis.
Attack volume is rising fast. Akamai's 2026 Apps, APIs and DDoS State of the Internet report (March 2026) states that average daily API attacks rose 113% year over year and that 87% of the organisations it surveyed had an API-related security incident in 2025.
Abuse arrives with valid credentials. The 2026 Thales Bad Bot Report (April 2026, covering 2025) found that 27% of bot attacks targeted APIs and that bots made up more than 53% of web traffic. These requests often use valid authentication and well formed calls, so perimeter controls and login protection alone do not stop them.
AI is accelerating both discovery and exposure. In March 2026 a security start-up reported that its autonomous agent had found 22 unauthenticated endpoints, among more than 200 documented ones, in McKinsey's internal AI platform, then chained SQL injection with an object-level authorisation flaw. McKinsey patched the issues and its forensics firm found no evidence of client data being accessed by any unauthorised party, but the case shows how quickly automated tools now find API weaknesses. See the McKinsey AI platform analysis.
The keys to APIs are themselves a target. API keys, OAuth tokens and service account credentials are non-human identities that rarely expire and are often over-privileged. When Dropbox disclosed in 2024 that attackers had compromised a back-end service account in Dropbox Sign, customer API keys and OAuth tokens were among the data exposed. See the Dropbox Sign breach analysis.
Standards bodies now treat APIs as a distinct discipline. NIST published SP 800-228, Guidelines for API Protection for Cloud-Native Systems, in June 2025 and updated it on 13 March 2026 with a list of API risks by category and recommended controls by lifecycle stage. In our view at NHI Mgmt Group, auditors will increasingly expect organisations to evidence API controls in their own right rather than under general application security.

How API failures happen, in business terms

Boards do not need code-level detail, but they should recognise the main failure types in the OWASP API Security Top 10 2023, because each maps to a question management should be able to answer with evidence.

OWASP API risk	What goes wrong, in plain terms	Business consequence	Evidence to ask for
API1 Broken Object Level Authorization	A logged-in caller can read or change records that belong to someone else by changing an identifier	Bulk exposure of customer data through normal-looking requests	Authorisation tests that try other users' records on every endpoint handling an ID
API2 Broken Authentication	Weak or missing checks on who is calling, poor token handling, no protection against password guessing	Account takeover, unauthorised access by anyone on the internet	Count of endpoints without authentication, and why each is public
API3 Broken Object Property Level Authorization	The API returns or accepts more fields than the caller should see or change	Leakage of sensitive fields, users raising their own privileges	Response schemas reviewed against data classification
API4 Unrestricted Resource Consumption	No sensible limits on request volume, size or cost	Outages, runaway cloud and third-party bills, scraping	Rate and cost limits per client, alerting on unusual consumption
API5 Broken Function Level Authorization	Ordinary users can call administrative functions	Fraud, mass changes, privilege escalation	Separation of admin APIs and tests that ordinary roles are refused
API6 Unrestricted Access to Sensitive Business Flows	A legitimate flow, such as buying, booking or signing up, is automated at scale	Scalping, inventory hoarding, promotion abuse, fake accounts	Business owners' view of which flows need anti-automation controls
API9 Improper Inventory Management	Old, test or undocumented API versions remain reachable	Attackers use the forgotten door with weaker controls	A complete, owned API inventory and a retirement process
API10 Unsafe Consumption of APIs	The organisation trusts data from partner and third-party APIs without checks	A supplier compromise flows straight into core systems	Third-party API register and validation of inbound data

The remaining two risks, Server Side Request Forgery (API7) and Security Misconfiguration (API8), are engineering hygiene issues that a mature testing programme should catch. In MITRE ATT&CK terms, API attacks most often appear as Exploit Public-Facing Application (T1190), Valid Accounts (T1078) and Steal Application Access Token (T1528).

Five questions for the board to ask

How many APIs do we expose, and how do we know the number is complete? A good answer gives a figure, separates internet-facing from internal and partner APIs, names an owner for each and explains how undocumented APIs are discovered from traffic rather than from developer declarations alone. Cloudflare's 2024 API Security and Management Report found that machine learning discovery identified about 31% more API endpoints than its customers had reported, so self-declared inventories should be treated as incomplete.
Which APIs handle customer, payment or regulated data, and has each been tested for authorisation flaws in the last year? Authentication tests are not enough. Ask specifically whether testers tried to read other customers' records, call administrative functions and change fields they should not change.
Would we notice a valid account pulling a hundred times more data than normal? The T-Mobile abuse ran for about six weeks. Ask what monitoring exists for volume, sequence and pattern anomalies per client and per key, and who responds out of hours.
Who owns the keys and tokens that call our APIs and the APIs we call? Ask how many API keys and tokens exist, how many have no named owner, how many have never been rotated and how many have broader scope than their use requires. See the API Key Management Guide.
Can an API ship to production without passing security gates? A good answer describes design review for new APIs, automated testing in the build pipeline, gateway onboarding as a condition of release and a documented exception route with expiry dates.

Red flags in management answers

"The web application firewall covers APIs": a firewall blocks malformed requests, but object-level authorisation abuse uses perfectly valid requests from logged-in users.
"All our APIs are behind authentication": authentication answers who is calling, not what they may see. API1, API3 and API5 all happen after a successful login.
An inventory built only from documentation or developer surveys: shadow and zombie APIs are by definition missing from those sources.
Penetration tests scoped to the website only: mobile app back ends, partner APIs and internal APIs exposed through cloud gateways are often out of scope.
No owner for API keys: keys created by former staff or retired integrations remain valid indefinitely.
Rate limiting described as "on" with no thresholds: default limits are usually far too generous to stop scraping by a patient attacker.

What good looks like

Area	Weak position	Good position
Inventory	Spreadsheet maintained by architects, updated yearly	Continuous discovery from gateway and traffic data, every API with an owner, data classification and lifecycle status
Design	Security reviewed after build, if at all	Specification-first design (for example OpenAPI) with threat modelling for APIs that touch sensitive data
Authorisation	Checked inconsistently in each service	Central policy for object and function level checks, tested automatically on every release
Machine credentials	Long-lived shared keys in code and configuration	Short-lived, scoped tokens; keys in a secrets manager with owners, rotation and revocation
Runtime protection	Generic firewall rules	Gateway enforcement, per-client rate and cost limits, behavioural detection of scraping and enumeration
Third-party APIs	Partner responses trusted as-is	Register of consumed APIs, input validation, contractual security requirements
Response	No API-specific playbook	Rehearsed playbook to revoke keys, block clients and assess data exposed per endpoint

NIST SP 800-228 frames these controls in two stages: pre-runtime controls applied during design and development, and runtime controls applied in operation, each with basic and advanced levels. That split is a useful way for the board to ask whether investment is balanced, because programmes often buy runtime tooling while design and testing remain weak, or the reverse.

Where to invest first

Priority	Investment	Why it comes first	Typical effort
1	API discovery and an owned inventory	Nothing else can be measured or protected until the estate is known	Weeks, using gateway, cloud and traffic data already available
2	Authorisation testing of high-risk APIs	The top OWASP risks are authorisation flaws that scanners miss	Targeted testing of the APIs that handle customer, payment and regulated data
3	Machine credential hygiene	Leaked or over-scoped keys turn a small exposure into a large one	Inventory, owner assignment, rotation and scope reduction
4	Runtime monitoring and rate limits	Detects abuse by valid accounts, which preventive controls do not stop	Gateway policies first, then behavioural detection
5	Security gates in the delivery pipeline	Stops the problem recurring as new APIs ship	Ongoing, owned by engineering with security standards

Small and large organisations: a smaller business with a handful of public APIs can often achieve priorities one to four with an API gateway it already pays for, disciplined key management and an annual specialist test. A large enterprise with thousands of APIs across business units usually needs dedicated discovery and runtime protection, a central API platform team and authorisation testing built into every pipeline. In both cases the decision to buy a specialist product should follow, not precede, an honest inventory. See the API Security Buyer's Guide and the API Gateway Security Guide.

Metrics to track

Inventory coverage: percentage of APIs observed in traffic that are in the inventory with a named owner and data classification. Target close to 100% for internet-facing APIs.
Authorisation test coverage: percentage of APIs handling sensitive data tested for object and function level authorisation in the last 12 months.
Unauthenticated endpoints: number of internet-facing endpoints that require no authentication, each with a recorded business reason.
Machine credential age: percentage of API keys and tokens older than the rotation policy, and number with no owner.
Time to detect anomalous consumption: measured in exercises where a test client pulls data at abnormal volume.
Retired versions: number of deprecated API versions still reachable, trending to zero.

Report these by business unit and trend them quarterly. A single "API risk score" from a tool is not a substitute, because it hides which of the questions above are unanswered. See the Board Cyber Risk Reporting Guide.

A 90-day plan

Days 1 to 15, establish ownership and scope: name an accountable executive for API risk, agree the definition of an API in scope (public, partner, internal, mobile back end) and collect existing inventories, gateway configurations and the last two years of API test reports.
Days 15 to 45, discover and classify: run discovery from gateway logs, cloud load balancers and traffic data; reconcile against documented APIs; assign an owner and data classification to every internet-facing API; list unauthenticated endpoints and deprecated versions.
Days 30 to 60, test the highest-risk APIs: commission authorisation-focused testing of the APIs that handle customer, payment and regulated data, using the OWASP API Security Top 10 as the minimum scope. Fix findings in order of data exposed.
Days 45 to 75, clean up machine credentials: inventory API keys and tokens, revoke those with no owner or no recent use, rotate long-lived keys and reduce scopes. Move keys out of code into a secrets manager.
Days 60 to 90, monitor and govern: set per-client rate and volume limits at the gateway, alert on enumeration and unusual consumption, write an API abuse response playbook and agree security gates for new APIs. Report the baseline metrics to the board.

Rollback and safety: introduce new gateway limits in monitor-only mode first, review what would have been blocked with the API owners, then enforce, so that legitimate partners and mobile apps are not cut off. See the API Abuse and Data Scraping Response Playbook.

Where identity fits

Every API call carries an identity: a customer session, an employee token, a partner's OAuth client or a service account key. API security is therefore partly an identity problem. Object-level authorisation decides what each identity may see; machine credentials decide who can call at all. Many organisations have far more API keys and tokens than human users, and they are governed far less well. Treat API clients as non-human identities with owners, scopes, expiry and monitoring. See the API Keys vs OAuth Tokens Guide.

Framework mapping

Framework	Reference	Relevance to API security
NIST CSF 2.0	ID.AM-02	Inventories of software, services and systems, including APIs
NIST CSF 2.0	PR.AA-05	Access permissions enforced with least privilege, the basis of object and function level authorisation
NIST CSF 2.0	DE.CM-09	Monitoring software and runtime environments for adverse events
NIST CSF 2.0	GV.OV-01	Board and leadership review of risk strategy outcomes
NIST SP 800-53 Rev. 5	CM-8, AC-3, SA-11, SI-4	Component inventory, access enforcement, developer testing, system monitoring
OWASP	API Security Top 10 2023; ASVS 5.0	Risk taxonomy and verification requirements for testing
NIST SP 800-228	Pre-runtime and runtime controls	API-specific control guidance for cloud-native systems

Common failure patterns

Treating API security as a product purchase: buying a runtime tool before knowing the inventory, then finding alerts nobody owns.
Testing authentication, not authorisation: test reports that confirm login works but never try another customer's records.
Mobile back ends assumed private: APIs built for a company app are reachable directly by anyone who inspects the traffic.
Old versions left running: version 1 stays live for one partner and lacks the controls added in version 3.
Long-lived keys in code: API keys committed to repositories or shared between environments and never rotated. See the LLMjacking analysis for how stolen keys are monetised.
No playbook for scraping: abuse is detected but nobody is authorised to block a partner or revoke a key quickly.

Practitioner checklist

Maintain an API inventory reconciled against observed traffic, with owner, data classification and lifecycle status.
Require authorisation testing (object, property and function level) for every API handling sensitive data, at least annually and on major change.
Record a business reason for every unauthenticated internet-facing endpoint.
Store API keys in a secrets manager, assign owners, set expiry and rotate on schedule.
Enforce per-client rate, volume and cost limits at the gateway, introduced in monitor mode first.
Alert on enumeration patterns and unusual data volumes per client and per key.
Retire deprecated API versions on a published schedule.
Keep an API abuse playbook covering key revocation, client blocking and data exposure assessment, and rehearse it yearly.

Standards and references

How NHI Mgmt Group can help

We provide independent assessments of API and non-human identity risk, board briefings and programme initiation support, including inventories of the API keys, tokens and service accounts that call your APIs. Our NHI Foundation Level Training Course helps security and engineering teams govern machine credentials. Contact us to arrange a briefing.

API Security Executive Briefing: Board Questions, Investment Priorities and a 90-Day Plan