API security testing means sending requests to an API on purpose to find weaknesses in access control, data exposure, limits and configuration. This glossary defines twelve terms that come up in buying conversations, using the OWASP 2023 API risk names where they apply.
The terms
| Term | Plain definition |
|---|---|
| API security testing | Checking an API by calling it, as different users, with unusual input, to see whether controls hold |
| OpenAPI specification | A machine-readable description of an API's operations, parameters and responses, often used as scanner input |
| Spec import | Loading that description into a tool so it knows which operations to test |
| BOLA | Broken object level authorization. One user can reach another user's object by changing an ID. OWASP API1:2023 |
| BOPLA | Broken object property level authorization. A user can read or write properties of an object they should not, which covers excessive data exposure and mass assignment. API3:2023 |
| BFLA | Broken function level authorization. A lower role can call a function meant for a higher one. API5:2023 |
| Unrestricted resource consumption | Missing limits on requests, sizes or spend. API4:2023 |
| Improper inventory management | Old versions, forgotten hosts and undocumented endpoints nobody tracks. API9:2023 |
| Introspection | A GraphQL feature that returns the schema on request |
| Fuzzing | Sending large numbers of varied or malformed inputs to provoke errors |
| Passive or baseline scan | Observes traffic and responses without sending attack requests |
| Active scan | Sends crafted attack requests to the target |
Two more worth knowing: a shadow API is an endpoint that exists in production but is not in your documentation or inventory, and a business flow is a sequence like checkout or sign-up that can be abused even when each call looks valid (API6:2023, unrestricted access to sensitive business flows).
How the terms show up in conversations
"We support OpenAPI import." Ask what happens when the spec is wrong or old. OWASP's testing guidance says documentation may be inaccurate or incomplete and should be verified.
"We test the OWASP API Top 10." Ask which of the ten the tool finds by itself, which need two accounts you provide, and which need a human. Access control risks need requests made as different users. Business flow abuse needs someone who understands the flow.
"We do a baseline scan." That means passive. It is safe in production, and it cannot find most authorization flaws.
"We scan active." That means attack requests, possibly including write methods. Ask about safe handling and rate ceilings.
"We find shadow APIs." Ask how. Common sources are traffic, client-side code, historical URLs, source code routes, and network scans, all of which the OWASP reconnaissance guidance lists. Each has blind spots.
Terms people confuse
- Authentication vs authorization. Authentication proves who you are. Authorization decides what you may do. BOLA, BOPLA and BFLA are all authorization failures.
- Scan vs penetration test. A scan is automated and repeatable. A penetration test adds human judgment, especially for logic flaws.
- Vulnerability vs misconfiguration. One is a flaw in code, the other is a setting. API8:2023 covers the latter.
A tip for buyers
Ask a vendor to define their terms using these names. If an answer sounds like a list of attack types without saying what needs to be provided, such as accounts or a spec, press for specifics.
A worked example using the terms
To see the vocabulary in action, take a short vendor call transcript, paraphrased, and translate it.
Vendor says: "We import your OpenAPI file, run a baseline scan on every pull request, and an active scan nightly against staging. We detect BOLA and BFLA using two accounts you provide."
Translation, term by term:
- "Import your OpenAPI file" means spec import. The tool will test the operations in your description. Ask what happens to operations that are missing from it.
- "Baseline scan on every pull request" means passive checks only. Expect findings about headers, cookies and error details, not authorization.
- "Active scan nightly against staging" means attack requests. Ask about write methods, rate ceilings and how the staging data is protected.
- "BOLA and BFLA using two accounts" means the tool can compare how two users are treated. Ask whether it also supports role accounts for function level checks, and anonymous callers.
Now a second statement: "We also discover shadow APIs from traffic." Translation: the tool looks at observed requests and compares them with documentation. Ask what traffic it sees: production, staging, or only the scan's own requests. A shadow API that is never called during the observation window will not appear.
A short checklist of follow-up questions
| Term in the pitch | Follow-up question |
|---|---|
| Spec import | What formats are supported, and what is reported when parsing fails? |
| Baseline scan | Which findings can it produce without sending attack requests? |
| Active scan | Can I limit methods, paths and request rate? |
| BOLA, BFLA, BOPLA | Which accounts do I need to provide, and how are results shown per account? |
| Introspection | Does the tool test for open introspection and field suggestions on GraphQL? |
| Fuzzing | Does it avoid flooding, and can I set a ceiling? |
| Shadow API | What data source does discovery use, and how often does it refresh? |
| Unrestricted resource consumption | Does it test limits, or just report missing headers? |
Using the glossary in your own documents
When you write a test plan or a questionnaire answer, use the same terms. "We test for BOLA with two seeded accounts on staging, weekly" says more than "we test authorization". It tells a reader the control, the method and the frequency.
It also helps in a review. If a colleague writes "API tested" in a ticket, ask which of these terms applies: passive or active, which accounts, which versions. Over time the team's records become comparable from one test to the next.
Terms that are likely to change
Names and numbering in the OWASP list differ between editions. The 2023 list is the one used here. Newer editions may rename or reorder items, so check the current version before you cite a number in a contract or a report. The ideas stay stable even when the labels move.
Related terms you may meet next
Once the twelve above are familiar, a few neighbors are worth knowing.
| Term | Plain meaning |
|---|---|
| Mass assignment | The server accepts fields it should not let the caller set, such as a role. A cause of property level flaws |
| Rate limiting | Capping how often a client can call, tied to resource consumption |
| Idempotency | Sending the same request twice has the same effect as sending it once, which helps with retries but also affects abuse testing |
| Scope | The agreed list of hosts, paths and methods a test may touch |
| Rules of engagement | The written terms of a test: scope, window, limits, contacts |
| False positive | A reported issue that is not real |
| False negative | A real issue the test did not report |
| Regression test | A test that checks an earlier fix still holds |
False negatives are the ones to worry about with scanners, because by definition you do not see them. That is why coverage, accounts and mode matter more than the finding count.
How to build your own one-page glossary
A shared vocabulary is cheap to build and pays back in every review. Start with the twelve terms above and add the words your team actually uses.
- Collect the terms from real documents. Read your last two test reports and your last questionnaire. Underline every term a newcomer would need explained.
- Write one sentence each. If a definition needs two sentences, the term is probably two terms.
- Add an example from your own API. "BOLA: user B reads user A's invoice by changing the invoice ID in the billing API" sticks better than an abstract line.
- Note the source. Where a term comes from a published list, name it and the edition, so people know where to check for changes.
- Put it where people look. A page in the engineering wiki linked from the test plan template beats a document nobody opens.
- Review it twice a year. Terms drift, tools change names, and new risks appear.
New joiners, sales engineers and auditors all benefit. When everyone means the same thing by passive, active and coverage, test results travel between teams without being misread.
Try it yourself
Open the demo and match each finding to one of the terms above.
Click through it at your own pace, or open it full screen.
Quick check
Is BOLA the same as IDOR?
They describe the same kind of weakness, a user reaching another user's object by changing a reference. BOLA is the name used in the OWASP API list.
Does a baseline scan test authorization?
Not in any meaningful way. Authorization testing needs requests made as different users.
Where can I see the official names for the ten API risks?
The OWASP API Security Top 10 2023 page lists them with their identifiers, such as API1:2023 for broken object level authorization. Check for a newer edition before quoting numbers.
Sources
Last reviewed: 19 October 2026.
