APIs have become a strategic necessity for companies to promote innovation and agility. Today’s end users demand access to confidential corporate information from any internet-connected device. Line-of-business functions now require APIs, and 83% of organizations view API integration as a crucial component of their business strategy.
However, the fear of unwarranted exposure to the valuable information these APIs exposes frequently tempers the financial incentive associated with this agility. By 2022, API abuses will be the most common attack method for data breaches in enterprise web applications, predicts Gartner.
A secure API can ensure the privacy of the data it handles by restricting access to only the Users, Apps, and Servers that have been permitted to use it. It ensures the accuracy of the data it receives from the clients and servers with which it works. Information will only be processed if it is certain that a third party has not changed it. An API must be able to handle requests and reliably process them to ensure that information is never lost.
This post will explore some of the most critical API security risks and their solutions.
1. Broken Object Level Authorization
APIs frequently expose endpoints that deal with object identifiers, leading to a problem with Level Access Control. By tampering with the ID of an object sent as part of the request, attackers can take advantage of API endpoints that are susceptible to flawed object-level authorization. Unauthorized access to sensitive information could result from this. Because the server component typically does not fully track the client’s state and relies on inputs like object IDs sent from the client to determine which objects to access, this problem is prevalent in API-based applications. Unauthorized access can lead to data loss, data manipulation, or data disclosure to uninvited parties. A full account takeover may also result from unauthorized access to objects.
How to prevent it
- Implement a suitable authorization system that depends on user policies and hierarchy.
- Every function that accepts input from the client to access a record in the database uses an authorization mechanism to verify that the logged-in user is authorized to carry out the requested action on the record.
- Prefer using random and illogical values as record IDs (GUIDs).
- Create tests to assess the authorization system. Avoid deploying test-breaking changes that are vulnerable.
2. Broken User Authentication
The mechanism for authentication in APIs is complicated and unclear. There may be misunderstandings among software and security engineers regarding the limits of authentication and the proper implementation methods. Additionally, because the authentication mechanism is public, attackers can easily target it. The authentication component is potentially open to numerous exploits because of these two factors. Because authentication mechanisms are frequently implemented incorrectly, attackers can compromise authentication tokens or take advantage of implementation flaws to temporarily or permanently assume other users’ identities. The security of APIs is compromised when the system’s capacity to identify the client or user is compromised.
There are two sub-issues:
- Lack of protection mechanisms: API endpoints that handle authentication must be handled differently from other endpoints and include additional security measures.
- Misimplementation of the mechanism: Without taking into account the attack vectors, the mechanism is used or implemented, or the use case is incorrect (e.g., an authentication mechanism designed for IoT clients might not be the right choice for web applications).
As a result, hackers can take over other users’ accounts in the system, read their data, and carry out sensitive tasks like sending personal messages and making financial transactions on their behalf.
How to prevent it
- Ensure you are familiar with all possible flows for API authentication (mobile, web, deep links that support one-click authentication, etc.).
- Check with your engineers to see what flow you missed.
- Review your authentication procedures. Make sure you comprehend their purpose and application. OAuth and API keys are not authentication methods.
- Don’t reinvent the wheel when it comes to password storage, token generation, and authentication. Use the guidelines.
- In terms of brute force, rate limiting, and lockout protections, credential recovery and forget password endpoints should be treated similarly to login endpoints.
- Use multi-factor authentication whenever possible.
- Use anti-brute force defenses to lessen the impact of dictionary attacks, brute force attacks, and credential stuffing on your authentication endpoints. This mechanism should be more stringent than your API’s standard rate-limiting mechanism.
- Use account lockout/captcha mechanisms to stop brute force attacks on particular users. Put weak-password checks in place.
- Client app/project authentication should be done using API keys rather than user authentication.
3. Excessive Data Exposure
Developers frequently expose all object properties without considering their sensitivity in anticipation of generic implementations, relying on clients to filter the data before it is shown to the user. Excessive Data Exposure can be easily exploited. Typically, it involves sniffing the traffic to examine the API responses and look for exposed sensitive data that shouldn’t be given back to the user.
Clients are the ones who filter the data for APIs. Since APIs are used as data sources, developers occasionally generically implement them without considering the exposed data’s sensitivity. Because it’s difficult to distinguish between legitimate data returned from the API and sensitive data that shouldn’t be returned without a thorough understanding of the application, automatic tools typically can’t detect this vulnerability. Excessive Data Exposure commonly leads to the exposure of sensitive data.
How to prevent it
- Never rely on a client’s side filter to remove sensitive information.
- Check the API responses to ensure only accurate data is contained in them.
- Before exposing a new API endpoint, backend engineers should ask themselves, “Who is the data consumer?”
- Steer clear of generic methods like JSON () and string (). Pick out only the properties you want to return instead.
- Organize sensitive and personally identifiable information (PII) that your application stores and uses, and examine all API calls that return PII to determine whether they raise security concerns.
- As an additional layer of security, implement a schema-based response validation mechanism. Define and enforce the data returned by all API methods as part of this mechanism, including any errors.
4. Broken Function Level Authorization
Authorization flaws frequently result from complex access control policies with numerous hierarchies, groups, and roles and a blurred line between administrative and regular functions. Attackers can access other users’ resources and administrative features by taking advantage of flaws.
For an attack to be successful, the attacker must make valid API calls to the API endpoint to which they shouldn’t have access. Users who are not logged in or are regular, non-privileged users may have access to these endpoints. Since APIs are more structured and the method of accessing specific functions is more predictable (e.g., changing the HTTP method from GET to PUT or changing the “users” string in the URL to “admins”), it is simpler to find these flaws in APIs.
A function or resource’s authorization checks are typically managed through configuration, though occasionally at the code level. Due to the variety of roles and groups that can be found in modern applications and the intricate user hierarchies, implementing proper checks can be confusing (e.g., sub-users and users with more than one role). Attackers can gain access to unauthorized functionality thanks to these flaws. Among the main targets of this kind of attack are administrative functions.
How to prevent it
- All your business functions should be able to call the same consistent and simple-to-analyze authorization module in your application. Such protection is frequently offered by one or more elements that are not part of the application code.
- Any access should be explicitly granted to specific roles to access any function, and the enforcement mechanism(s) should disable all access by default.
- Check your API endpoints for function-level authorization flaws while keeping in mind the application’s group hierarchy and business logic.
- Ensure that each of your administrative controllers derives from an abstract administrative controller that executes authorization checks according to the user’s group or role.
- Ensure that administrative features inside a standard controller implement authorization checks based on the user’s group and role.
5. Mass Assignment
Mass Assignment frequently results from tying client data (like JSON) to data models without the proper properties filtering based on a whitelist. Attackers can alter object properties without authorization by describing object properties, investigating additional API endpoints, reading the documentation, or including extra object properties in request payloads.
Understanding business logic, object relationships, and API structure are typically prerequisites for exploitation. Since APIs are designed to expose the application’s underlying implementation and the names of its properties, mass assignment is easier to exploit.
The use of functions that automatically bind client input to internal objects and code variables is encouraged by modern frameworks. Attackers can update or change sensitive object properties that the creators never intended to be exposed to using this technique. Exploitation may result in data manipulation, privilege escalation, evading security measures, etc.
How to prevent it
- If possible, avoid functions that automatically assign client input to internal objects or variables.
- Only include the properties on the whitelist that the client should update.
- Use built-in tools to add properties that clients shouldn’t access to a blacklist.
- Explicitly define and impose schemas for the input data payloads, if necessary.
6. Security Misconfiguration
Insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, incorrectly configured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information are common causes of security misconfiguration.
Attackers frequently look for flaws that have not yet been patched, popular endpoints, or unprotected files and directories to gain unauthorized access to or knowledge of the system. Any level of the API stack, from the network to the application level, can experience security misconfiguration. Automated tools can find and take advantage of misconfigurations, such as unused services or outdated options. Security errors can reveal private user information and system specifics, which may result in a complete server compromise.
How to prevent it
The API life cycle should include the following:
- A repeatable hardening procedure enables the quick and simple deployment of an environment that is properly secured.
- An assignment to update and review configurations for the entire API stack. Cloud services, API components, and orchestration files should all be reviewed (e.g., S3 bucket permissions).
- Access to static assets and a secure communication channel for all API interactions (e.g., images).
- A routine automated procedure to evaluate the efficacy of the configuration and settings across all environments.
Furthermore:
- Defining and enforcing all API response payload schemas, including error responses, will stop attackers from receiving valuable information such as exception traces and other information.
- The ensure API can only be accessed using the specified HTTP verbs. Disabling all other HTTP verbs is recommended (e.g., HEAD).
- APIs that anticipate being used by browser-based clients (like the front end of a WebApp) should implement an appropriate Cross-Origin Resource Sharing (CORS) policy.
7. Injection
When untrusted data is sent to an interpreter as part of a command or query, injection flaws like SQL, NoSQL, Command Injection, etc., happen. The attacker’s malicious data may trick the interpreter into carrying out unintended commands or gaining unauthorized access to data.
Attackers will inject malicious data into the API using any available injection vectors (such as direct input, parameters, integrated services, etc.), anticipating that it will be sent to an interpreter.
Injection flaws are frequently discovered in OS commands, XML parsers, LDAP or NoSQL queries, and ORM. When reviewing the source code, these errors are simple to find. Scanners and fuzzers can be used by attackers. The injection can lead to information disclosure and data loss. It may also lead to DoS or a complete host takeover.
How to prevent it
- Data must be kept apart from commands and queries to prevent injection.
- Carry out data validation using a single, reliable, and up-to-date library.
- Verify, sanitize, and filter any data supplied by the client or obtained from integrated systems.
- Special characters should be escaped using the target interpreter’s specific syntax.
- Pick a secure API with a parameterized interface.
- Keep the number of records that can be returned to a minimum to avoid mass disclosure in the event of injection.
- Verify incoming data with enough filters to only permit legitimate values for each input parameter.
- Establish strict patterns and data types for each string parameter.
8. Improper Assets Management
Since APIs expose more endpoints than conventional web applications, accurate documentation is crucial. Deprecated API versions and exposed debug endpoints are just a couple of the problems that can be mitigated with a proper inventory of hosts and deployed API versions.
Since outdated API versions are frequently not patched, it is simple to compromise systems using them without dealing with the cutting-edge security measures that may be in place to defend more recent API versions.
Finding and/or repairing vulnerabilities is more challenging when the documentation is outdated. Lack of asset inventories and retirement plans results in unpatched systems being used, which exposes sensitive data to leakage. Due to contemporary concepts like microservices, which make applications simple to deploy and independent, it’s common to find hosts with unnecessary API exposure (e.g., cloud computing, k8s). Through outdated, unpatched API versions connected to the same database, attackers may access confidential information or even take control of the server.
How to prevent it
- Make an inventory of all API hosts and note key information about each one, paying particular attention to the API environment (such as production, staging, test, or development), the network access rights the host should have (such as public, internal, or partner access), and the API version.
- List integrated services and significant document characteristics, including their function in the system, the type of data exchanged (data flow), and their sensitivity.
- Ensure that your API is thoroughly documented, covering everything from authentication to errors, redirects, rate limiting, the cross-origin resource sharing (CORS) policy, and endpoints with all their associated parameters, requests, and responses.
- Use open standards to generate documentation automatically. Be sure to mention the documentation created for your CI/CD pipeline.
- Provide those with permission to use the API with access to the API documentation.
- Don’t just use API security firewalls for the current production version of your APIs; use them for all exposed versions.
- Steer clear of using non-production API deployments with production data. These endpoints should receive the same level of security care as the production ones if this is unavoidable.
- When newer API versions include security improvements, conduct a risk analysis to determine the mitigation measures needed for the older version. For instance, determine whether it is possible to backport the improvements without compromising API compatibility or whether you need to quickly remove the older version and force all clients to upgrade.
9. Insufficient Logging & Monitoring
Attackers can continue attacking systems, maintain persistence, and pivot to more systems to tamper with, extract from, or destroy data when insufficient logging and monitoring combined with missing or ineffective integration with incident response. According to most breach studies, it typically takes more than 200 days for a breach to be discovered, and external parties more often than internal processes or monitoring do so.
Attackers use the lack of logging and monitoring to their advantage to abuse systems covertly. Without monitoring or with insufficient logging and monitoring, it is nearly impossible to keep track of suspicious activity and respond to it quickly. Attackers have plenty of time to completely compromise systems without visibility into ongoing malicious activity.
How to prevent it
- Record any denied access, invalid input, or failed authentication attempts.
- Logs should be created in a format that can be read by a log management tool and contain enough information to pinpoint the malicious actor.
- Logs should be treated as sensitive data, and their integrity at rest and in transit should be ensured.
- Set up a monitoring system to monitor the infrastructure, network, and API functionality at all times.
- Gather and manage logs from all hosts and components of the API stack using a Security Information and Event Management (SIEM) system.
- Create personalized dashboards and alerts to help identify suspicious activity and take immediate action.
