salman
Author
Table of Contents
26
Read this in 30 seconds: The OWASP API Security Top 10 is the definitive ranked list of the most critical API vulnerabilities, and the 2023 edition is still the active standard in 2026. It exists because API flaws don’t behave like traditional web app bugs. They’re authorization failures and business logic abuse that scanners miss. BOLA (Broken Object Level Authorization) sits at number one and shows up in roughly 40% of all API attacks. This guide explains every one of the ten risks with real attack scenarios and concrete fixes, covers how they apply to REST, GraphQL, and increasingly to LLM-powered APIs, and shows why manual testing matters where automated tools fall short.
Your APIs are the most attacked, least tested part of your entire application. And most teams don’t even know how many they have.
95% of organizations experienced an API security incident. The vast majority never saw it coming because their scanners weren’t built to catch the way APIs actually break.
Here’s what makes API security different and dangerous. Traditional web application vulnerabilities like cross-site scripting and SQL injection have signatures. A scanner can recognize them. API vulnerabilities are mostly authorization failures and business logic abuse, which means they’re invisible to rule-based scanning. There’s no signature for “this user can access another user’s data by changing a number in the URL.” That requires understanding intent, and scanners don’t understand intent.
This is exactly why the OWASP API Security Top 10 exists as a separate list from the web application Top 10. APIs are a fundamentally different attack surface, and the people defending them need a framework built specifically for how APIs get attacked.
The current edition was published in 2023, and in 2026 it remains the active standard. It draws from real-world penetration testing data, bug bounties, and security research to rank the ten most critical API risks. This guide walks through every single one, explains how attackers actually exploit it, and gives you concrete fixes. By the end, you’ll understand not just the list but the thinking behind API security.
The OWASP API Security Top 10 is a ranked list of the ten most critical API security risks, maintained by the Open Web Application Security Project.
OWASP is a nonprofit focused on improving software security, and its Top 10 lists are the closest thing the industry has to a universal standard. Most people know the original OWASP Top 10 for web applications. The API Security Top 10 is its dedicated counterpart for application programming interfaces, and it exists because API vulnerabilities are genuinely different.
The list draws from real data: penetration testing results, bug bounty findings, and security research from across the industry. That grounding in real-world attacks is what makes it credible. It’s not a theoretical list of what could go wrong. It’s a ranked summary of what actually goes wrong, ordered by how common and how damaging each risk is.
The current edition was published in 2023, replacing the previous 2019 list. The 2023 update made meaningful structural changes that reflect how attackers shifted their tactics. It added three new categories, consolidated two others, and rebalanced the rankings to match the current threat landscape.
Here’s the critical thing to understand about why the OWASP API Security Top 10 is separate from the web application list. The web application Top 10 targets browser-based vulnerabilities like cross-site scripting and insecure deserialization. The API list focuses on authorization logic failures, business flow abuse, and behavior-based vulnerabilities that rule-based scanners miss entirely. These are different problems requiring different testing approaches and different defenses.
Translation: if you’re only testing your APIs against the web application Top 10, you’re testing for the wrong things. APIs break differently, and the OWASP API Security Top 10 is the map of how.
Before diving into each risk, it’s worth understanding how the 2023 list evolved from 2019, because the changes reveal where attackers focused their energy.
Three new categories were added. Unrestricted Access to Sensitive Business Flows (API6) addresses business logic abuse, where attackers exploit legitimate functionality in harmful ways. Server-Side Request Forgery (API7) entered the list reflecting the rise of cloud-hosted APIs. Unsafe Consumption of APIs (API10) addresses the growing risk of trusting data from third-party APIs in an era of supply chain attacks.
Two categories were merged. The old Excessive Data Exposure and Mass Assignment categories combined into Broken Object Property Level Authorization (API3), because they shared the same root cause: improper authorization validation at the object property level.
The top of the list stayed stable. Broken Object Level Authorization remained at number one, Broken Authentication held number two, and these authorization-focused risks continue to dominate because they remain the easiest and most rewarding targets for attackers.
The pattern across these changes is clear. The 2019 list was a starting point. The 2023 version reflects two real shifts in how attackers operate: the move toward business logic abuse and the rise of cloud-hosted APIs that introduce new attack surfaces. Understanding this evolution helps you see where API security is heading.
Now the core of this guide. Here’s every risk on the OWASP API Security Top 10, what it means, how attackers exploit it, and how to fix it.
What it is: BOLA happens when an API fails to verify that the user requesting an object is actually authorized to access that specific object. The endpoint checks that you’re logged in but not that the data you’re requesting belongs to you.
How it’s exploited: This is the classic “change the ID in the URL” attack. An API endpoint like /api/orders/12345 returns order 12345. An attacker changes it to /api/orders/12346 and gets someone else’s order. The API authenticated the user but never checked object ownership. Attackers automate this, iterating through IDs to harvest entire databases of records belonging to other users.
Why it matters: BOLA is the number one API security risk and has been since 2019. It appears in roughly 40% of all API attacks, making it the single most common API vulnerability. The reason it persists is that object-level authorization is genuinely hard. In a fast-moving development environment, developers building dozens of endpoints easily overlook the check on each one.
How to fix it: Implement authorization checks on every single endpoint that accesses an object, verifying that the authenticated user owns or has permission to access that specific resource. Don’t rely on unpredictable IDs (like UUIDs) as your only defense, because obscurity is not authorization. Enforce object-level checks server-side on every request, every time.
What it is: Broken Authentication covers all the ways authentication mechanisms fail, allowing attackers to assume other users’ identities or bypass authentication entirely.
How it’s exploited: Attackers use stolen authentication tokens, credential stuffing with leaked password databases, and brute-force attacks against login endpoints that lack rate limiting. Weak token generation, tokens that don’t expire, passwords accepted without complexity requirements, and authentication endpoints without protection all open the door.
Why it matters: Authentication is the front door. Broken Authentication has held the number two position since 2019 because compromising it gives attackers legitimate-looking access that’s hard to detect. Once an attacker has a valid token, everything they do looks authorized.
How to fix it: Implement strong authentication with multi-factor authentication where possible. Use short-lived tokens that expire and rotate. Enforce rate limiting and account lockout on authentication endpoints to stop brute force and credential stuffing. Validate tokens properly on every request. Follow established standards for authentication rather than building your own.
What it is: This category, new in its merged form for 2023, covers failures to check permissions at the level of individual object properties. It combines the old Excessive Data Exposure and Mass Assignment risks.
How it’s exploited: Two flavors. In the data exposure direction, an API returns more fields than the user should see, like returning a full user object including password hashes or internal flags when only the name was needed. In the mass assignment direction, an attacker sends extra fields in a request that get blindly written to the object, like adding "role": "admin" to a profile update and gaining admin privileges.
Why it matters: Both directions share the same root cause: the API doesn’t validate authorization at the property level. It trusts that the client will only send and receive appropriate fields, which attackers happily violate.
How to fix it: Explicitly define which properties each user role can read and write. Never blindly bind client input to internal objects. Use allowlists for writable properties rather than accepting whatever the client sends. Return only the fields the user is authorized to see, filtering server-side rather than relying on the client. This is an area where manual testing matters, because automated tools struggle to detect property-level authorization flaws reliably.
What it is: APIs require resources to satisfy requests: bandwidth, CPU, memory, storage, and sometimes paid third-party services like SMS, email, or biometric validation. When these aren’t limited, attackers can exhaust them.
How it’s exploited: An attacker floods an API with requests, exhausting compute resources and causing denial of service. Or they abuse expensive operations, like triggering thousands of SMS messages or third-party API calls that the victim pays for per use, driving up operational costs dramatically.
Why it matters: This category, broadened from the old “Lack of Resources and Rate Limiting,” reflects that resource abuse isn’t just about availability. It’s also about cost. An attacker can run up a massive bill by abusing paid integrations exposed through your API.
How to fix it: Implement rate limiting on every endpoint. Set configuration controls on execution timeouts, maximum upload sizes, records returned per request, and third-party spending limits. Monitor resource consumption and alert on anomalies. Treat any operation that costs money or significant resources as something that must be explicitly limited.
What it is: BFLA happens when an API fails to properly restrict access to functions based on user role. Regular users can access administrative functions they shouldn’t.
How it’s exploited: An attacker discovers that an administrative endpoint like /api/admin/deleteUser doesn’t actually check whether the caller is an admin. They call it as a regular user and it works. Attackers probe for these endpoints by guessing administrative function names and testing whether role checks are enforced.
Why it matters: Complex access control policies with different hierarchies, groups, and roles, plus unclear separation between administrative and regular functions, tend to lead to authorization flaws. BFLA gives attackers access to privileged operations, often the most damaging ones.
How to fix it: Enforce role-based access control consistently on every function. Deny by default, granting access only to explicitly authorized roles. Keep administrative functions clearly separated and verify authorization on every privileged operation server-side. Don’t rely on hiding admin endpoints, because attackers will find them.
What it is: This new 2023 category addresses business logic abuse. It covers APIs that expose sensitive business flows without protecting against automated abuse of that legitimate functionality.
How it’s exploited: Think of a flow like purchasing limited-edition products, posting comments, or making reservations. An attacker automates the flow to abuse it: scalping all the limited inventory with bots, flooding a system with spam, or gaming a process designed for human use. The individual requests are legitimate. The harm comes from the scale and automation.
Why it matters: This category recognizes that not every attack exploits a technical vulnerability. Some exploit the business logic itself, using the application exactly as designed but in harmful ways. These are invisible to traditional vulnerability scanning because nothing is technically broken.
How to fix it: Identify your sensitive business flows and protect them against automated abuse. Techniques include device fingerprinting, detecting non-human patterns, CAPTCHA where appropriate, and rate limiting tuned to the business flow rather than just the endpoint. The goal is to make automated abuse impractical while keeping legitimate use smooth.
What it is: SSRF occurs when an API fetches a remote resource based on a user-supplied URL without validating it. The attacker tricks the server into making requests on their behalf.
How it’s exploited: An attacker supplies a URL pointing to an internal service, the cloud metadata endpoint, or another sensitive target. The API dutifully fetches it, giving the attacker access to internal resources they couldn’t reach directly. In cloud environments, SSRF against metadata services can expose credentials and lead to full environment compromise.
Why it matters: SSRF entered the API Top 10 in 2023 reflecting the rise of cloud-hosted APIs. As more APIs run in cloud environments and fetch resources based on user input, SSRF became a critical pathway into internal infrastructure.
How to fix it: Validate and sanitize all user-supplied URLs. Use allowlists of permitted destinations rather than trying to blocklist dangerous ones. Disable unnecessary URL schemes and prevent access to internal IP ranges and cloud metadata endpoints. Isolate the resource-fetching functionality so that even if SSRF occurs, the blast radius is limited.
What it is: Security Misconfiguration covers the broad category of insecure default configurations, incomplete setups, verbose error messages, missing security headers, and other configuration-level weaknesses.
How it’s exploited: Attackers probe for misconfigurations: unnecessary HTTP methods enabled, missing security headers, overly verbose error messages that leak internal details, default credentials left in place, or unpatched systems. Each misconfiguration is a potential foothold.
Why it matters: Misconfigurations are common because modern systems have countless configuration options, and getting every one right across a large API surface is difficult. They remain on the list because they’re easily exploitable and offer access with little effort.
How to fix it: Harden configurations systematically. Disable unnecessary features and HTTP methods. Implement proper security headers. Suppress verbose error messages in production. Keep systems patched. Use a repeatable, automated hardening process so configurations stay secure as your API evolves, rather than drifting over time.
What it is: This category addresses the risk of not knowing what APIs you have. Outdated API versions, undocumented endpoints, and forgotten test or staging APIs create unmonitored attack surface.
How it’s exploited: Attackers find and target the API you forgot about. An old, deprecated version still running without the security fixes applied to the current version. A staging endpoint exposed to the internet. An undocumented API that bypasses your security controls. These shadow and zombie APIs are exactly where breaches happen because nobody is watching them.
Why it matters: You can’t secure what you don’t know exists. As organizations build more APIs faster, inventory management becomes a real security problem. The 2023 update emphasized maintaining accurate API inventories precisely because so many breaches trace back to forgotten endpoints.
How to fix it: Maintain a complete, current inventory of all your APIs, including versions and environments. Retire deprecated versions promptly. Ensure staging and test APIs aren’t exposed to production traffic or the internet. Document every endpoint. Use discovery tooling to find shadow APIs you didn’t know about. Visibility is the foundation of API security.
What it is: This new 2023 category addresses the risk of trusting data from third-party APIs. Developers tend to trust data received from third-party APIs more than user input, and that trust is exploitable.
How it’s exploited: An attacker compromises or impersonates a third-party API that your application consumes, then feeds your application malicious data. Because your application trusts that source, it processes the malicious data without the validation it would apply to user input, leading to injection, data corruption, or compromise.
Why it matters: Supply chain attacks are increasingly common, and applications increasingly ingest data from third-party sources. This category recognizes that the API you call is now part of your attack surface. The 2023 addition reflects how interconnected modern applications have become.
How to fix it: Validate and sanitize data from third-party APIs exactly as you would user input. Never assume a third-party source is trustworthy just because it’s not a direct user. Use secure connections, verify the integrity of received data, review third-party data sources regularly, and ensure all incoming data conforms to expected formats regardless of its source.
Look at the OWASP API Security Top 10 and a pattern jumps out. The top of the list is dominated by authorization failures: BOLA at number one, Broken Authentication at two, Broken Object Property Level Authorization at three, Broken Function Level Authorization at five. Four of the top five risks are authorization problems.
This isn’t a coincidence. It reflects a fundamental truth about APIs. Unlike web applications where users navigate through a controlled interface, APIs expose direct access to objects and functions. Every endpoint is a potential door, and each one needs its own authorization check. Miss the check on a single endpoint and you’ve created a vulnerability.
The challenge is that authorization is contextual and stateful in ways that are hard to test automatically. A scanner can check whether an endpoint requires authentication, but it can’t easily determine whether the authenticated user should be allowed to access this specific object or perform this specific function. That requires understanding the application’s intended access model, which is exactly the kind of judgment that automated tools lack.
This is why manual testing matters so much for API security. The most damaging API vulnerabilities, the authorization failures and business logic abuse that top the OWASP API Security Top 10, are precisely the ones that automated scanners miss. A skilled human tester who understands the application’s access model finds these flaws by reasoning about what should and shouldn’t be allowed, then testing whether the API enforces it.
The OWASP API Security Top 10 was written with REST APIs in mind, but its risks apply broadly. Understanding how it maps to GraphQL and emerging LLM-powered APIs is increasingly important in 2026.
GraphQL. GraphQL APIs are vulnerable to most categories on the list. BOLA applies when resolvers don’t check object-level authorization. Broken Authentication applies when query batching bypasses rate limits, letting attackers send many operations in a single request. Unrestricted Resource Consumption is a particular concern because GraphQL’s flexible queries can be crafted to demand enormous resources through deeply nested or complex queries. The OWASP API Security Top 10 absolutely applies to GraphQL, just with GraphQL-specific exploitation techniques.
LLM-powered APIs. This is the frontier. As applications expose LLM agents that call downstream APIs on behalf of users, new attack surfaces emerge that don’t fit neatly into the 2023 list. A critical example: when an LLM agent calls downstream APIs on behalf of a user, object-level authorization checks often get skipped entirely. The agent acts with broad permissions, and the careful per-user authorization that should apply gets lost in the handoff. BOLA in AI agents is an emerging risk that combines the classic number-one API vulnerability with the new world of autonomous AI systems.
The lesson is that the OWASP API Security Top 10 provides the foundational framework, but you have to apply its thinking to new architectures. The underlying risks, especially authorization failures, persist across REST, GraphQL, and AI-powered APIs. The exploitation techniques evolve, but the root causes stay remarkably consistent.
Knowing the risks is one thing. Testing for them is another. Here’s how to actually verify your APIs against the OWASP API Security Top 10.
Automated scanning catches some of it. Tools can find certain misconfigurations, missing rate limits, and known vulnerability patterns. Automated testing is a useful starting point for the more signature-based risks like Security Misconfiguration and some resource consumption issues.
Manual testing catches the rest, which is most of it. The authorization failures and business logic abuse that dominate the OWASP API Security Top 10 require human testers. As security researchers consistently note, automated testing is unreliable for property-level authorization, because it typically works through filtered word lists rather than genuine reasoning about access. Manual penetration testing is recommended specifically for BOLA, Broken Object Property Level Authorization, and business flow abuse, where understanding the application’s intended behavior is essential.
A complete testing approach combines both. Use automated tools for breadth and the signature-based risks, then apply skilled manual testing for the authorization and business logic flaws that automation misses. This is the same hybrid principle that applies across modern security testing: automation for coverage, humans for the nuanced vulnerabilities that actually cause the worst breaches.
This is where dedicated API penetration testing earns its value. Testing your APIs against the full OWASP API Security Top 10 properly requires a tester who understands authorization models, can reason about business logic, and knows how attackers chain API vulnerabilities together. At XHack, our API security testing combines automated coverage with human expertise focused precisely on the authorization and business logic flaws that scanners miss, the ones sitting at the top of this list. Whether you bring in a specialized provider or build the capability in-house, the key is ensuring someone is actually testing for the authorization failures that dominate the OWASP API Security Top 10, not just running a scanner and calling it done.
Knowing the risks and testing for them is the foundation, but turning the OWASP API Security Top 10 into an ongoing program is what actually keeps your APIs secure over time. Here’s how to operationalize it.
Start with inventory. You cannot secure what you don’t know exists, which is why Improper Inventory Management is on the list. Before anything else, build a complete picture of every API you run, including versions, environments, and the forgotten staging and deprecated endpoints. This inventory is the foundation everything else builds on. Run discovery tooling to surface shadow APIs, then keep the inventory current as your API surface grows.
Prioritize authorization. Since four of the top five risks on the OWASP API Security Top 10 are authorization failures, your program should focus disproportionately on authorization. Establish a consistent authorization model, enforce object-level and function-level checks on every endpoint, and make authorization testing a standard part of your development and review process. This single focus addresses the majority of your real risk.
Shift security left. Don’t wait until an API is in production to think about the OWASP API Security Top 10. Integrate security into the development process. Review authorization logic during code review. Test for these risks before deployment. The earlier you catch an authorization flaw, the cheaper it is to fix and the less exposure you carry.
Test continuously, not annually. Your APIs change constantly as you ship new endpoints and modify existing ones. A once-a-year test against the OWASP API Security Top 10 leaves you exposed for the other 51 weeks. Build continuous testing into your pipeline, supplemented by periodic deep-dive manual testing for the authorization and business logic flaws that need human expertise.
Monitor in production. Even with great testing, some issues only surface in production. Monitor your APIs for the attack patterns associated with the OWASP API Security Top 10: enumeration attempts that signal BOLA probing, authentication anomalies, resource consumption spikes, and unusual business flow patterns. Feed these signals into your security operations so you can detect exploitation attempts in real time.
Close the loop. When testing finds a vulnerability, fix it, then verify the fix actually worked through retesting. A finding isn’t resolved until it’s confirmed fixed. Track your progress against the OWASP API Security Top 10 over time so you can see your API security posture improving rather than just accumulating a backlog of known issues.
Even teams that know the OWASP API Security Top 10 make predictable mistakes. Here’s what to avoid.
Relying only on automated scanning. This is the biggest mistake. Teams run an API scanner, get a clean report, and assume they’re secure. But the authorization failures that dominate the OWASP API Security Top 10 are exactly what scanners miss. A clean automated scan tells you almost nothing about your BOLA exposure. You need manual testing for the risks that matter most.
Securing the web frontend but not the API. Many breaches happen because a company tested its web application thoroughly but never tested the APIs powering it. Attackers go straight for the API, bypassing the frontend entirely. If your application has APIs, and almost every modern application does, those APIs need dedicated testing against the OWASP API Security Top 10.
Forgetting about old API versions. Teams deploy a new, secure version of an API but leave the old vulnerable version running. Attackers find and exploit the old one. Improper Inventory Management exists precisely because forgotten endpoints are such a common breach source. Retire deprecated versions promptly.
Trusting internal and third-party APIs. Teams apply rigorous validation to user input but blindly trust data from internal services and third-party APIs. Unsafe Consumption of APIs is on the list because this trust is exploitable. Validate data from every source, not just direct user input.
Treating API security as a one-time project. API security against the OWASP API Security Top 10 is not a box you check once. Your APIs change constantly, and each change can introduce new vulnerabilities. Teams that treat it as a one-time audit fall behind quickly. Make it continuous.
Assuming obscurity equals security. Using hard-to-guess IDs or undocumented endpoints feels like protection, but it isn’t. Attackers find undocumented endpoints and guess or harvest IDs. The OWASP API Security Top 10 is clear that real authorization checks, not obscurity, are what protect your APIs.
As of 2026, the 2023 edition remains the active, current standard for the OWASP API Security Top 10. It replaced the 2019 list, adding three new categories (Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, and Unsafe Consumption of APIs) and merging two others into Broken Object Property Level Authorization. OWASP updates its lists periodically based on evolving threat data, so it’s worth checking the official OWASP API Security Project page for any newer release, but the 2023 version is what you should be securing against right now.
Broken Object Level Authorization, known as BOLA, is the most common API vulnerability and holds the number one spot on the OWASP API Security Top 10. It appears in roughly 40% of all API attacks. BOLA occurs when an API verifies that a user is authenticated but fails to check whether that user is authorized to access the specific object they’re requesting. The classic attack is changing an ID in a URL or request to access another user’s data. It has been the top API risk since 2019 because object-level authorization is genuinely difficult to implement consistently across every endpoint.
The regular OWASP Top 10 targets web application vulnerabilities like cross-site scripting and insecure deserialization, which are largely browser-based. The OWASP API Security Top 10 focuses on API-specific risks: authorization logic failures, business flow abuse, and behavior-based vulnerabilities that rule-based scanners miss. APIs are a fundamentally different attack surface because they expose direct access to objects and functions. If you only test your APIs against the web application Top 10, you’ll miss the authorization and business logic flaws that cause most API breaches.
Partially. Automated tools can detect certain risks like some misconfigurations, missing rate limits, and known vulnerability patterns. But the risks that dominate the OWASP API Security Top 10, particularly the authorization failures (BOLA, BFLA, Broken Object Property Level Authorization) and business logic abuse, require manual testing. Automated testing is unreliable for property-level authorization because it works through word lists rather than reasoning about access models. The most effective approach combines automated scanning for breadth with skilled manual penetration testing for the authorization and business logic flaws that automation cannot reliably catch.
Yes. GraphQL APIs are vulnerable to most categories on the OWASP API Security Top 10. BOLA applies when resolvers fail to check object-level authorization. Broken Authentication applies when query batching bypasses rate limits. Unrestricted Resource Consumption is especially relevant because GraphQL’s flexible query structure allows deeply nested or complex queries that demand excessive resources. The risks are the same, but the exploitation techniques are GraphQL-specific, so testing GraphQL APIs requires understanding both the OWASP API Security Top 10 and GraphQL’s particular characteristics.
LLM-powered APIs introduce new attack surfaces that don’t fit neatly into the 2023 list. The most significant emerging risk is BOLA in AI agents: when an LLM agent calls downstream APIs on behalf of a user, object-level authorization checks often get skipped because the agent operates with broad permissions. This combines the number-one API vulnerability with the new world of autonomous AI. As organizations deploy AI agents that interact with APIs, applying the authorization principles from the OWASP API Security Top 10 to these AI-mediated interactions becomes critical, even though the framework wasn’t originally written with AI agents in mind.
That’s the complete guide to the OWASP API Security Top 10 in 2026.
The 2023 edition remains the active standard, and its central lesson is unmissable: API security is overwhelmingly about authorization. Four of the top five risks are authorization failures, led by BOLA, which alone accounts for roughly 40% of API attacks. These aren’t the vulnerabilities scanners catch. They’re the ones that require understanding how an application is supposed to work and testing whether it actually enforces those rules.
If you take one thing from this guide, make it this: testing your APIs against the OWASP API Security Top 10 properly requires more than automated scanning. The risks that cause the worst breaches, the authorization and business logic flaws at the top of the list, demand skilled human testing. Combine automation for breadth with manual expertise for depth, maintain a complete inventory so you’re not leaving forgotten APIs exposed, and treat every endpoint as a door that needs its own lock.
Your APIs are your most attacked attack surface. The OWASP API Security Top 10 is the map of how they break. Use it to make sure someone is testing for the right things, because the alternative is finding out the hard way, alongside the 95% of organizations that already have.
Follow Us on X: @xhackio
Related articles
Read this in 30 seconds: AI for CTF went from novelty to standard toolkit in about eighteen months. An autonomous [&hell...
Read this in 30 seconds: Unrestricted AI for penetration testing means an AI system that does not add artificial refusal...
Read this in 30 seconds: The cheapest AI pentest tool depends entirely on how you define cheap. If you mean […] ...
