iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
SaaS APIs connect customer-facing features, partner integrations, and internal services. Because they can expose application logic and sensitive data, their security needs explicit ownership—not an assumption that a login screen or a perimeter firewall protects every request. The “ticking time bomb” is a metaphor, not a prediction: the risks are real, but neither OWASP’s framework nor the sources cited here establish that every SaaS faces an imminent breach or a countdown to one.
Why API security is a product and business concern
An API is often how an application reads or changes a customer’s records, invokes a privileged feature, or exchanges data with another service. A flaw in those checks can expose information or let a caller perform an action beyond their authority. The OWASP API Security Project frames its work around helping people develop, design, and maintain APIs securely.
API risk is not limited to a coding error that lets someone bypass a login. A legitimate, authenticated user may still be allowed to see another customer’s object, change a property they should not control, or invoke a function intended for a more privileged role. Other risks involve expensive operations, automatable business flows, unsafe server-side requests, configuration, overlooked API versions, or data received from third parties.
Use the OWASP API Security Top 10 as a checklist, not a score
The OWASP API Security Top 10 – 2023 names ten risk categories. It is an awareness framework, not a statistical ranking of breach frequency and not a risk score for a particular company. Use it to prompt questions about your own architecture and controls.
#1 Best Overall
API1: Broken Object Level Authorization
Whenever a request names a record, file, account, or other object, the server needs to check that the caller may access that particular object. A valid login does not establish ownership or permission. Ask: if a caller changes an object identifier in a request, does the server still verify access to the requested object before returning or changing it?
API2: Broken Authentication
Authentication is the process of establishing who or what is making a request. Weaknesses in that process can let an attacker impersonate a user or misuse a credential. Review how credentials and tokens are issued, stored, transmitted, validated, and revoked, and check that authentication controls cover every API route that requires an identity.
API3: Broken Object Property Level Authorization
Permission to access an object does not automatically mean permission to read or change every property on it. Sensitive fields may be returned unnecessarily, or a caller may be able to alter properties reserved for the system or a privileged role. Ask which properties each API response may expose and which properties each caller may update.
Rank #2
API4: Unrestricted Resource Consumption
Requests can consume processing time, memory, storage, or paid third-party capacity. If resource-heavy operations have no suitable limits, abuse may cause service disruption or unexpected cost. Identify expensive or repeatable operations and decide what limits and monitoring are appropriate for their use and business impact.
API5: Broken Function Level Authorization
Function-level authorization determines which actions a caller may perform. A user who can access an ordinary feature should not thereby gain access to an administrative or otherwise privileged function. Check that the server enforces role and permission requirements for each function, rather than relying on the interface to hide actions from unauthorized users.
API6: Unrestricted Access to Sensitive Business Flows
Some flows are legitimate features but become harmful when automated or used at scale—for example, a process that can be repeated to create fake accounts or gain an unfair advantage. Identify business flows whose abuse could harm customers or the business, then consider how to detect and limit misuse without treating every automated request as malicious.
Rank #3
API7: Server-Side Request Forgery (SSRF)
If an API accepts a URL or other input that causes the server to make a request, an attacker may try to make that server contact an unintended destination. Find features that fetch or otherwise act on user-supplied locations, and assess whether the server can be induced to reach destinations it should not access.
Recommended Free Tools
API8: Security Misconfiguration
Insecure settings can undermine otherwise sound application logic. Review configuration across environments and API components, including whether debug functionality or unnecessary access is exposed. Treat configuration review as part of deployment and maintenance, not only as a one-time setup task.
API9: Improper Inventory Management
Teams cannot reliably protect APIs they do not know are running. Keep an inventory of deployed hosts, API versions, and endpoints, including older or less visible interfaces and debug endpoints. Compare the inventory with what is actually deployed so that an abandoned version does not remain outside normal review.
Rank #4
- API Security in Action
- Manning Publications
- ABIS BOOK
API10: Unsafe Consumption of APIs
Your service may rely on data or behavior from another API. Do not assume that a third-party response is safe just because it came from a familiar integration. Identify external API inputs and treat returned data as untrusted when your application processes or uses it.
Authentication and authorization answer different questions
Authentication asks, “Who or what is making this request?” Authorization asks, “May this caller perform this action on this object and its properties?” A successful authentication check is not an authorization decision. For a request to read a record, the service may need to establish the caller’s identity, confirm the caller may access that specific record, and restrict the fields returned. For a request that changes data, it may also need to verify that the caller may perform that action and modify those particular fields.
Free tools Windows power users keep installed
One-click scans. No signup required.
OWASP’s 2023 release announcement says that three of the five top-listed items in its list relate to authorization. That is a description of the categories in the framework, not a finding that authorization flaws account for a particular share of real-world incidents. See the OWASP announcement.
Best Value
Turn the checklist into an API security practice
A list of questions is a starting point, not a substitute for assessing the application. Make API security part of product and engineering ownership so that decisions about data access, privileged actions, integrations, and operational limits are made deliberately.
- Map what exists. Maintain an inventory of API hosts, versions, endpoints, integrations, and the teams responsible for them. Reconcile it with deployed systems and update it as the product changes.
- Trace sensitive operations. For important reads, writes, and business flows, document the caller, the object or data involved, and the action being requested. Identify where the server makes the relevant access decision.
- Assign ownership. Ensure a named product or engineering owner is responsible for the API’s security decisions and maintenance, with security practitioners involved where the impact or complexity warrants it.
- Review changes and configuration. Include authorization, exposed properties, resource use, integrations, and deployment configuration in design and change reviews. Revisit assumptions when a new client, role, endpoint, or API version is introduced.
- Assess actual risk. Prioritize work using the data and functions exposed, the architecture, plausible threats, and the consequences for your customers and business. Where internal expertise is insufficient, an application-specific API security assessment may help identify issues the checklist cannot decide.
Why the Top 10 cannot tell you your SaaS’s risk level
OWASP cautions that its risk-rating method does not account for threat-agent likelihood or the technical details of an individual application, either of which can significantly change exploitation likelihood. It also does not determine business impact for a particular organization. Therefore, the order of the categories is not a score or priority order for your SaaS; teams need to assess their own architecture, likelihood, impact, and risk tolerance. OWASP explains these limits in its API Security Risks material.
The project’s 2023 release notes say its public call for data received no contributions; the list was developed from the team’s experience, review by API security specialists, and community feedback. OWASP’s release notes and methodology and data explain that context. The list is useful for awareness, but it should not be presented as an empirical census or a measured rate of API breaches.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
