APIs are a key ingredient for building applications that are open and can integrate with other applications and services.
Yet with the openness and visibility of APIs comes a challenge: APIs can create additional security risks, as they increase the number of ways in which malicious actors could get into applications and cause chaos. Therefore, when developing APIs, careful design and application of security controls is essential.
But panic not, DevOps engineers. In this article, we’ll take a look at seven strategies you can follow throughout the software development lifecycle to maximize API security.
Hide All API Security Clues
Malicious users live in all corners, and giving them valuable clues that could lead to attacks is a serious offense. While most organizations have some security controls in place, they can actually be viewed as a disadvantage, because attackers have nearly unlimited time and the benefit of surprise. They can attack anytime, and usually when no one is looking. One typical example is when you have a user authenticating with a username and a password. In the case of the user supplying a correct username but a wrong password, it’s recommended not to expose that information through the response in any way, even when a response code is coupled with a reason, such as:
Status Code: 401, Reason: WRONG_PASSWORD
Clearly, this will give an attacker a clue that the username is correct, and he will switch his focus to finding the correct password. A reasonable response to this situation would be:
Authenticate First, Authorize Next
Anything that is sensitive and private must be barred behind an authentication flow to decide user/client identity. There are many ways to perform authentication—and for added security, it’s recommended to establish a multi-factor type where two or more pieces of evidence are used to determine the requester. For APIs, it is common to use some kind of access token obtained through an external process—for instance, when signing up or through a protocol (Oauth2). The authentication keys are meant to be secret, and it’s recommended that a secret management store be used to automate the whole process. However, authentication alone is not enough—and as a result, there should be an authorization step to determine what resources the identified user has access to. In that case, there are ways to check for proper authorization, such as via content-based access control (CBAC), role-based access control (RBAC) or policy-based access control (PBAC), and ensure that business data remains fully protected against unapproved access.
Enforce Encryption All the Way Through
API security during the request-response cycle is only as strong as its weakest link. A fundamental security requirement, of course, is to encrypt the communication flow using the latest cryptographic protocols. This is to ensure proper protection of authentication credentials in transit, such as API keys, passwords, and tokens (among other things). You need to consider adding extra layers on top, such as mutually authenticated certificates, so that both parties exchanging info are certain that their API communication is safe from tampering.
Use Throttling and Resource Quotas
When protecting your APIs against abuse or DDoS attacks, it is necessary to have rules that restrict usage once certain criteria are met. This would include requests per time unit, bandwidth limits, or monthly quotas. You can also apply more fine-grained rules for backend-intensive operations, per user or per organization, allowing availability and fair usage of business services.
Use Proper Validation
By securing APIs effectively, we typically mean securing the request-response lifecycle. Input is injected via the URL as parameters or the request body as content, and this is received by the API backend to process. Most attacks originate from this area, as it’s the easiest way in for cases of missing security controls. Some requests, if carefully crafted, can penetrate many layers across the infrastructure.
For parameters, it is recommended not to trust any sort of input strings or objects, and always validate against a specific set of rules and expectations. (Help from industry standard sanitation libraries is beneficial in this situation.) For request payloads, which can include headers, body text, or attachments, it’s important to validate against conformance and integrity. No data leaks or too-obvious content should be exposed in the response entity.
Make Your APIs RESTful
REST API design is a proven method used to cut boilerplate and complexity, thus making applications simple to understand and extend. By using a REST framework, you abide by a set of implementation guidelines that help increase API security by design. For example, you can apply whitelisting to specific HTTP methods and reject anything that does not satisfy the contract. Instead of responding with text, you would follow an HTTP return code table that has a semantic response and does not unintentionally expose any sensitive information.
Use Auditing and Logging
Auditing should never be skipped. Any sort of logging should be systematic and independent, and resistant to log injection attacks. Any subject or entity can be audited, and this should be used for detecting and proactively deterring attacks. This is especially important in the container ecosystem as only the bare minimum elements are used to run an app. The security threats that affect containers could also create forthcoming threats to APIs, so proper inspection tools must be in place.
Additional API Security Resources
Understanding how best practices in security can be applied to APIs and protecting the underlying platforms from risks are important steps towards risk mitigation. Furthermore, as APIs are typically part of a larger infrastructure, it’s necessary to offer a holistic design approach in terms of security and compliance. For that reason, I highly recommend checking out the Ultimate Guide for Container Security.
APIs are essentially applications, and a complete understanding of the threats and risks of this domain is required. Check out the OWASP Top 10 Application Security Risks to learn how the Twistlock platform can reduce them in practice.
- Application Security
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
AWS Fargate Security: Runtime Defense with Twistlock 2.5Read the Blog
Cloud Native Forensics: Security Incident Response in Twistlock 2.5Read the Blog
Announcing Twistlock 2.5: GA Release NotesRead the Blog
GitOps 101: What Is GitOps, and Why Would You Use It?Read the Blog
DevSecOps Learning Resources: How to Learn to Do DevSecOpsRead the Blog