Application Programming Interfaces (APIs) contribute to a substantial amount of modern software application development. APIs are multidisciplinary, data driven and can be used for a number of applications, including microservices, web pages, mobile, the Internet of Things (IoT) and more. With the flexibility and capability, however, come the vulnerabilities and threats. This article will cover the top steps to secure API throughout the software development lifecycle (SDLC).
All the major industries – including finance, retail healthcare and critical infrastructure – utilize APIs. APIs also have real-life applications including autonomous vehicles, SMART devices, SaaS and more. Gartner predicted that, by 2022, the majority of data breaches will involve some kind of API abuse or misuse. Understanding the importance of managing API-related risk, the Open Web Application Security Project (OWASP) released its OWASP API Security Top 10 list in September.
The OWASP API Security Top 10 list addresses vulnerabilities that, combined with threats, contribute to cybersecurity risk. According to the OWASP API Security Top 10, Excessive Data Exposure, Security Misconfiguration, Insufficient Logging & Monitoring, et al., contribute to security risk. SDLC security teams can review the OWASP API Security Top 10 list to better understand the vulnerabilities and the threats that hackers can bring to IT environments.
OWASP API Security Top 10 Explained
1. Broken Object Level Authorization – Object identifiers help developers to unambiguously identify data objects to make authorizations at a single, micro-function level. This approach, unfortunately, has its shortcomings. For one thing, Object Level Authorizations introduce complexity to the process. APIs create attack points at endpoints to object identifiers and widen the attack surface.
We recommend threat modeling your implementation to understand whether or not hackers can gain access to objects (where they can wreak further havoc), e.g., by guessing object ID values. Ensure that the authorization process checks each access request. Use random IDs and don’t rely on IDs set by the client.
2. Broken Authentication – if authentication mechanisms are not implemented incorrectly, which can happen often, cyber attackers can compromise an application. Bad actors can compromise authentication tokens or other authentication components to gain access to user identities along the attack surface. This can lead to the hacker using the mechanism vulnerability as an attack point to compromises API security. Examples include credential stuffing with any number of username and password combos to try and gain entry and brute force attack.
ThreatModeler recommends standardizing user endpoint security approaches. Carefully follow the requirements outlined in your Application Security Verification Standard (ASVS) authentication implementation. ASVS is also published by OWASP. A general rule of thumb is to make sure to have a strong security requirement in place before leaving an unauthenticated API endpoint exposed on an unsecured network, e.g. the internet.
Excessive Data Exposure – don’t allow overly broad access to data objects through an API. Restrict the API to only access the data it needed for that request. In order for secure API use to occur, programmers need to set filters to limit the data exposed to a client. If there is no filter mechanism, the server side may send more data than is needed.
We recommend threat modeling to identify the accessible data elements to map out data information flows between the endpoint and client. You will then have a better understanding of your attack surface and where adequate filtering is needed. When you implement filtering, perform all of it on the server-side, not on the client. If you filter on the client, it can turn off the filter and receive all of the information.
Lack of resources and rate limiting – It is important to set restrictions to the size and/or number of resources that a client or user can request via API. There is only a certain level of resources that APIs should consume before compromising security. If rate limiting is not implemented, cybercriminals can abuse API servers from the performance side, leading to a Denial of Service (DoS) or brute force. Bad actors can target APIs to invoke procedures that utilize a lot of computation power and memory.
ThreatModeler once again recommends threat modeling to determine what rate-limiting controls should be implemented. Limit the payload sizes of what the server is receiving and define container resources.
Broken Function Level Authorization – authorization flaws may occur when there are complex access control policies. If function levels are not consolidated, simplified or streamlined, hackers may gain access to resources and administrative functions. Also known as micro-level function authorizations, complex policies can create vulnerabilities for cybercriminals to exploit.
We recommend restricting access with a standard, simplified authorization approach (deny by default). Do not allow function level authorizations.
Mass Assignment – filtering comes into play once again with client binding data, which occurs when programmers bind (synchronize) UI elements to data sources to allow for data editing. Binding client provided data occurs, for example, with JSON and filtering can occur based on a whitelist (items considered trustworthy or acceptable). In order to exploit server-client side relationships, attackers can gain an understanding of object properties through:
- Guesswork
- Reviewing documentation
- Detecting API endpoint locations
- Inputting object properties in request payloads
Once exploited, hackers can manipulate object properties, craft an API request to find out where certain data objects are and make an external call to it. Validate payloads before storing them.
Security misconfiguration – configuration flaws, e.g. incomplete or insecure setup can render an API setup susceptible to cyberattacks. Examples include unnecessary or misconfigured HTTP, verbose error messages that reveal private, sensitive information, security misconfigurations in open cloud storage, Missing Transport Layer Security (TLS), security headers or Cross-Origin Resource Sharing (CORS) Policy.
ThreatModeler recommends hardening your API, first by making necessary patches and updates to underlying technology. Threat model your attack surface, and conduct testing for vulnerabilities and security misconfigurations.
Injection – oftentimes, hackers will inject malicious code, as part of a command or query. Once inside – for example with SQL, NoSQL or some other injection flaw – hackers can further compromise a system and cause serious damage. Injections represent one of the most prevalent forms of cyberattacks. Hackers can insert SQL injections via API to solicit unauthorized commands or access restricted data.
We advise that users validate inputs against whitelisted inputs and implement parameterized queries. Set restrictions on the filter to limit the data records by a query.
Improper asset management – without the proper, updated documentation, APIs can expose more endpoints than other data sets. It is important to keep updated with the latest API versions to avoid the bugs and vulnerabilities that outdate dAPIs can bring. Version control is a consideration to be made because APIs go through their own end-of-life cycles. Implementing the right level of API lifecycle “housekeeping” where you’re not only updating APIs, but cleaning up after outdated APIs so they can’t be invoked. Previous ports or folders that are no longer used are removed or made unwritable.
ThreatModeler recommends making a proper inventory of the APIs being used, making each function standard and ensuring that endpoint restrictions are made. Prioritize API security based on the threats and vulnerabilities that constitute security risk, then harden the infrastructure.
Insufficient Logging and Monitoring – one of the biggest weaknesses involving APIs has to do with a lack of adequate logging, monitoring. ThreatModeler recommends logging security events adequately with sufficient data for forensic use. The log information should be stored securely, but remain accessible to SIMS tools. Threat modeling can help identify the right data that needs to be logged for security purposes.
ThreatModeler Will Ensure Secure API for Your Enterprise
Making server-client relationships as simple and straightforward as possible, while managing API content lifecycles will help to ensure a more secure SDLC. As OWASP has recommended, threat modeling will help organizations to clearly visualize their attack surface, to make informed risk management decisions. Threat modeling will help you to think like a hacker to better understand how s/he can gain access to your API infrastructure.
ThreatModeler is an automated tool that takes the guesswork out of creating threat models for your enterprise. Out-of-the-box, professionals with minimum technical understanding can build a threat model with all the components, connectors and users needed. ThreatModeler integrates with threat libraries from OWASP, CAPEC, AWS and Azure, plus IT ticketing systems that drive collaboration. To discover how ThreatModeler is the right tool for your DevSecOps program, we recommend scheduling a live demo. You can also contact us directly to speak with a threat modeling expert.