API Security Common Mistakes

As per Rapid’s 4th annual State of APIs Report, 70% of developers indicate they will increase API usage this year, while 63% note that they utilized more APIs in 2022 than they did the previous year. With growing API adoption there has been an increase in vulnerabilities seen with the production APIs.

APIs have become a popular target for attackers. Designing and building secure APIs by following security best practices is critical to protecting your customer data and applications. This article highlights common mistakes that are seen with API Services.

Improper Authorization and access control

While developers barely miss authentication, the same is not true about authorization and access control. Often, it is seen that the authorization checks and access control are either completely missing or not properly implemented.

For example, an adversary while analyzing the browser requests on an online library management website observes that the HTTP request includes a header X-Borrower-ID set as 73851. On tampering with the X-Borrower-ID value to 73852 in the request, the adversary gets a 200 OK response and can see and modify the data of other library users.

Recommendations:

Before performing any action, determine if the authenticated user has ownership over the specific object to perform that action.

Implement authorization checks that take below aspects into consideration:

• access control at the user level,
• have access policies and rules defined, and
• implement separation of duties for diverse types of users

Using an authentication mechanism that can be bypassed

While introducing APIs to a system, the authentication mechanism and its resiliency become one of the most crucial security aspects. We must ensure that there are no weak links or backdoors left that can be used to bypass the authentication.

Example: Adapting OTP-based authentication would not be able to secure your APIs if you fail to put the right controls in place. An API that does not put a limit on how many times one can try an invalid OTP or the expiry of an OTP after a certain time or after it is used could aid an adversary in bypassing the authentication.

Recommendations:

• Identify all the authentication flows including the legacy ones and ensure all of them have the right controls in place
• Ensure all the authentication flows have brute force prevention, rate limiting, and account lockout capabilities
• Avoid writing your own custom authentication mechanism, use the standard approach
• Enforce a strong password policy and implement multifactor authentication
• Enforce all critical validations such as authenticity, validity, and/or signatures of tokens
• Avoid sending anything sensitive in plain text and in an insecure manner (for example: do not send any sensitive data as part of the URL parameter)

Ignoring Security Headers for APIs

A lot of developers and security professionals live with the notion that security headers are not at all required for APIs. That’s not true, there are several security headers that should be used with APIs to maintain its security.

Recommendations:

Here are the key headers that you should not forget to set with the API response:

Content-Security-Policy Response Header

To prevent any drag-and-drop style clickjacking attack you are required to set below response header for your APIs:

Content-Security-Policy: frame-ancestors ‘none’ OR

Content-Security-Policy: frame-ancestors ‘self’

Cache-Control Response Header

To avoid sensitive information from getting cached, you must set the below header as part of the response:

Cache-Control: no-store

Strict-Transport-Security Header

Everyone agrees that all communication should happen over a secure TLS connection, and this is no different when it comes to APIs.

Strict-Transport-Security: max-age=31536000; includeSubDomains

X-Content-Type

To prevent browsers from performing MIME sniffing, and inappropriately interpreting responses as HTML.

X-Content-Type-Options: nosniff

Content-Type

To specify the content type of the response. This should be application/json for JSON responses.

Content-Type: application/json

X-Frame-Options

To protect against drag-and-drop style clickjacking attacks.

X-Frame-Options: DENY

Example:

Let’s consider an online library that has 100,000+ daily users with an influx of 100 new users daily, it would be reasonable to impose a rate limit of 60 requests per minute on the new user registration API. It is important to monitor the API traffic closely, and as the number of users and registrations continue to grow, it will be necessary to adjust and raise the rate limit accordingly.

Recommendations:

• Put your API service behind a gateway so that you can apply security controls
• Configure rate limit along with burst limit for your API Analyze and identify a suitable rate of request per endpoint instead of using a common one for all
• Configure granular rate limiting by making use of parameters such as User Agent, IP Addresses, Destination host, Referrer, etc. Example: If a given API is serving both Mobile and Browser then you can configure different rate limits for both clients based on user-agent
• Avoid resource exhaustion and server starvation by putting a limit on file downloads
• Build error handling independent of rate limiting to be prepared to handle the worst-case scenario
• Take different data flows and their specific requirements into consideration while defining rate limits. Example: Suppose your API Service is calling a legacy database that cannot handle heavy load, then the same should be considered while configuring the rate limit
• Monitor the API logs and activities against the rate limit you configured to improvise rate limiting when needed

Allowing unencrypted and/or insecure HTTP traffic

Unencrypted traffic allows an adversary to view a legitimate user’s network traffic and obtain any sensitive information exchanged. Unencrypted communication is known to be exploited by governments and ISPs to track users and inject JavaScript-serving ads.

Even when a server allows only HTTPS traffic still it can be susceptible to man-in-middle attacks if it is supporting Insecure Transportation Security protocols or weak ciphers.

Recommendations:

• Do not allow HTTP traffic, configure your server to redirect HTTP requests to HTTPS.
• You should allow only strong ciphers on your server to ensure secure communication over the API calls.
• You should disable TLS 1.1, TLS 1.0, SSL 3.0 and use TLS 1.2 or higher or higher for secure communication

Lack of logging and monitoring

Lack of proper logging and monitoring of your services would impair you while analyzing any suspicious activities on your infrastructure. In today’s world, where attacks have exponentially grown, both logging and monitoring are critical from a security standpoint. While logging ensures that critical data is captured and made readily available, monitoring ensures that the same data is analyzed properly to proactively act on any problems.

Below are some of the reasons why you should not ignore logging and monitoring:

• Logging and monitoring give you visibility into what’s happening across your IT infrastructure
• Log data contains critical information such as exceptions, errors, and edge cases seen at run time, fixing those issues would make the service more resilient
• Log data also captures suspicious activities that can enable you to act on security incidents
• Logging is important but is of no use without proper monitoring.

Recommendations:

• Ensure the log being written has all the critical details that you require for your analysis
• Use a standard format for writing logs so that they can easily be fed to popular log monitoring solutions
• Ensure logging all critical events such as failed authentication attempts, access denials & unauthorized access, input validation errors, etc.
• Preserve confidentiality and integrity of logs at rest and in trasnit
• TEncrypt the logs at rest and make use of hash comparison to ensure integrity has not been compromised
• Send logs over HTTPS, which will take care of preserving confidentiality and integrity in transit
• Deploy and configure a monitoring system to monitor all the API functioning along with monitoring other infrastructure services
• Use a Security Information and Event Management (SIEM) solution to be able to efficiently aggregate and analyze log data from all components of your APIs
• Employ dashboards and alerts to notify and act on suspicious activities

Relying on Client-Side validation

While client-side input validation provides a good user experience and quick response, it doesn’t provide much protection when it comes to preventing a security incident.

All client-side checks can easily be bypassed by setting up a proxy between the device and the server and modifying the request when it reaches the proxy. Hence it is important to enforce and revalidate all client-side checks/Operations at the server end.

Recommendations:

Here are the recommendations that should be followed:

• For any input that comes from a user or some other untrusted source, make sure that input validation for the same takes place at the server end.
• It is recommended to take the whitelisting approach of input validation where for any input field only an allowed set of characters can be considered valid for a given field
• It is also recommended to be as restrictive as possible and enforce length, format, and allowed character sets checks.
• While doing any critical operation such as logout, password reset, etc. make sure that the validation takes place on the server side. (Example: token invalidation should take place at the server end, merely deleting the token at the client end would not be enough).

In conclusion, securing the APIs is as important as any other piece of application code. This paper presented the common myths and mistakes often seen across API implementations. Remember, cybersecurity is an ever-evolving domain, so our learnings and best practices should be, too. We should keep an eye on new and emerging threats.

Author: Sandeep Kumar Singh (Director, Cybersecurity)

Editors: Gregory Levinsky (Marketing Content Specialist) & Josh Gaddy (VP, Director, Developer Advocacy)

Article Reference: API Security Common Mistakes — Pentestmag