What is API?
API is the Application Programming Interface. This is a common language in servers to communicate with each other, in simple words API interfaces different applications (it may be an internal application or a third-party application) and transacts the data between them, while doing so, it acts as an abstract layer and separates the Application from the actual infrastructure that is used by the system. API is usually used to modernize the development and facilitates Development teams to reuse the code.
Examples of APIs are as follows:
- Google Maps integration in Mobile/ Web Application (Third Party)
- Integration of Payment Gateway (Third Party)
- Front End to Back End Communication in Applications happens through API calls
Why API Security?
Due to the rise in the use of APIs in every sector of Information technology, and moreover, since APIs tend to expose application logic and sensitive data, APIs have become the main target for hackers. Hence, it is significant to concentrate on and improve the security related to APIs.
A partial list of API Vulnerabilities
- Broken Object Level Authorization
Object-level authorization is an access control mechanism that is commonly applied at the code level to validate that the respective user only access objects that they have the privilege to access.
There are chances that attackers may exploit API endpoints that are vulnerable to broken object-level authorization. They can manipulate the ID of the object that is in the API call (Request). If they are successful, attackers will get unauthorized access to the sensitive data. This may lead to unauthorized access to sensitive data. This issue is very common in API-based applications because the server component generally does not fully track the client’s state, and instead, depends more on parameters like object IDs, that are sent from the client to make your mind up which objects to access.
How to Prevent Broken Object Level Authorization
- User Policies and Hierarchies should be defined and based on which the appropriate authorization mechanism should be implemented.
- The Authorization mechanism should comprise logic that should check if the logged-in user has the relevant privilege to access/ perform the requested action on the record in every function that receives the input from the client to access a record from the database.
- Prefer to use random and impulsive values as GUIDs for records’ IDs.
- To write test cases to evaluate the authorization mechanism. Test Engineers should not allow deploying any vulnerable changes that break the tests.
- Broken User Authentication
Authentication in API is often a complex process and since multi-factor authentication or credential-based authentication is hard to be implemented in API. The API Endpoints responsible for authentication are easily targeted by attackers.
APIs rely on the tokens-based system, the tokens are embedded into the calls to authenticate the clients. As APIs rely on session tokens embedded into the calls to authenticate clients, If the API does not have the necessary information for authentication may be wrong token implementation, then there is a chance that attackers gain access to the system. On the other hand, long-lived tokens also allow the attacker to persist, compromising the system indefinitely.
How to Prevent:
- The authentication flows should be listed and verified, and no flow should be missed.
- Use the standard methods in Token Generation. Authentication and Storage of Passwords
- Reset Password and Forget Password should be treated as login endpoints in terms of brute force, rate limiting, and lockout protection
- Multifactor authentication should be implemented at appropriate places in the system.
- Implement the account lockout/captcha method to avoid brute force beside specific users. Implement weak-password checks.
- Avoid API keys for user authentication but they can be used at client app/ project authentication.
- Lack of Resource and Rate Limiting
There should be a limitation on the number of API requests from the same client given the time, if this is not adopted in the coding then there are chances that the API client can request access to multiple resources/ records at a given instant of time. This will overload the application server to serve the requests paving the path to Denial-of-Service attacks. The lack of rate-limiting also encourages hackers to perform brute-force attacks on authentication endpoints.
How to Prevent
- There should be limitations set to the client on how many times an API can be called within the given timeline.
- If the client exceeds the number of API Requests, then throw them an alert stating that the limit is exceeded and can proceed after a certain time.
- Server-Side validation to be implemented for Query string and request body parameters specifically the one that controls the number of records to be returned in the response.
- Tools like Docker makes it easy to limit memory, CPU, number of restarts, file descriptors, and processes.
- To Specify and limit the maximum size of data on all incoming parameters and payloads such as maximum length for strings and a maximum number of elements in arrays.
- Mass Alignment
Certain Modern frameworks allow developers to use the functions that bind client-provided data (for example JSON) to the data models, variables, or internal objects. This will provide an option for the hackers to modify object properties that will lead to Data Tampering, bypassing security mechanisms, and many more.
The exploitation of this kind mostly requires a clear understanding of the business logic, object relations, and API architecture. The exploitation of mass assignment is easier in APIs since by design they expose the underlying implementation of the application along with the property’s names.
How to Prevent
- Unless it is necessary, avoid binding client input data into variables and internal objects.
- Always Whitelist only the properties that should be updated by the client.
- Implement a mechanism to blacklist properties that should not be accessed by clients.
- If relevant, clearly describe and enforce schemas for the input data payloads.
- Security Misconfiguration
Security misconfiguration is due to insecure default configurations of one or multiple options of the following:
- Incomplete or ad-hoc configurations
- Open cloud storage
- Misconfigured HTTP headers
- Unnecessary HTTP methods
- Permissive Cross-Origin resource sharing (CORS),
- Verbose error messages containing sensitive information.
How to Prevent
- Scheduler or manual Task to review if all the configurations are correct and updated across the entire API stack. The review should contain orchestration files, API components, and cloud services
- A secure communication channel should be placed to check all API interaction access to Static assets.
- Scheduler to check the effectiveness of the configuration and settings in all environments.
- Make sure that API can only be accessed by the specified HTTP verbs. All other HTTP verbs should be disabled (e.g. HEAD).
- To have a mechanism in place to prevent exception traces and any valuable data to be sent to attackers.
- Should implement Cross-Origin Resource Sharing (CORS) policy.