APIs are the core of today’s modern applications. But, the critical application data and logic they expose make them juicy targets for bad actors.
Most of us remember the Equifax API security breach which cost the company $1.14 billion. Other API vulnerabilities like Facebook and Venmo also came with hefty price tags and compromised millions of accounts.
API security will continue to be a going concern. API abuses will be the most frequently exploited attack vector resulting in data breaches for enterprise web applications by 2022 [Gartner].
It’s no wonder that APIs are prime targets. The majority of vulnerability testing tools scan APIs once they are in production. Often these are part of periodical penetration tests (pen tests) or audits. Once testing is complete, the security team shares the vulnerabilities with the engineering team. Eventually, engineers take time away from feature development to patch and fix.
The problem with this approach of course is that the vulnerabilities are live in production long before they are found. Hoping your pen tester finds API vulnerabilities is not going to cut it. This is especially true if you are running complex APIs like GraphQL, which pen testers struggle to test effectively.
That is the process if you have an API testing program. Many teams lack the security knowledge or time, or both, to have an API security framework in place.
Security can no longer be an afterthought to functionality. Teams need to step up their API security testing programs in both the design and development phases.
Designing a Secure API Platform
Keeping your APIs secure requires multiple tools in your arsenal. This is especially true when it comes to designing your API. To keep your company and your data protected, you need to consider everything from who can access an API to how you are protecting yourself from known vulnerabilities.
We recommend building a solid plan around the following areas when you are designing your API:
Access Control: Ensure that internal APIs stay private. Restrict access to only the users that need it. Practice the principle of least privilege.
Rate Limiting: Control the number of requests a user can make to your API to prevent abuse (like DDoS). This also controls programming mistakes like endless loops.
Data Exposure: Check that your API isn’t revealing more than you would like. Be careful that your API isn’t returning extraneous or confidential data.
Vulnerability Identification: Protect your Web API from common weak spots, like injections, that are easily exploitable by bad actors. This is one of the more nuanced areas of API security, as it requires testing inputs and outputs, and fixing vulnerabilities once they are found.
You can limit API security concerns by thinking through these security considerations in the design phase. But it doesn’t remove that possibility all together.
Testing API Security in Development
No one wants vulnerabilities in their API to make it into the wild. At StackHawk we believe in security testing in CI/CD, before an application or API is shipped to prod. Testing for vulnerabilities in the development stage is one of the best possible ways to step up your API security.
We are seeing the rise of developer-centric security tools that make it simple to add security testing to CI/CD. With dev-centric tooling, you can find and fix vulnerabilities on every merge. This means you can have faith that the API you are shipping is protected from vulnerabilities.
There are different types of tools out there that catch different types of vulnerabilities.
Dynamic Application Security Testing (DAST)
DAST scanners work by simulating malicious attacks against your running API. You can run dev-centric DAST in pipeline, the same way as unit tests or integration tests. We love DAST for a couple of reasons.
Since it tests your running application, it is less likely to find false positives. If DAST finds a vulnerability, it is present in your application.
DAST finds the juicy stuff! DAST finds most of the OWASP Top 10, as opposed to other forms of security testing like SCA.
DAST isn’t language dependent. DAST has you covered even if you are using a more obscure language like Rust or Kotlin for your API.
While DAST is typically thought of as a tool for application security testing broadly, it is an incredibly effective way to test any form of API including GraphQL, REST, and SOAP.
Software Composition Analysis (SCA)
SCA finds vulnerabilities in open source libraries. These tools will examine the libraries your API uses to make sure they do not have any known common vulnerabilities and exploits (CVE). SCA will also provide you with critical knowledge should new vulnerabilities be discovered.
Static Application Security Testing (SAST)
Static application security testing scans the code base of the API or application for patterns that indicate a potential vulnerability. More recently, companies have built SAST tools that scan the openAPI specification file for potential vulnerabilities. It is important to note that SAST is language dependent, so make sure you find a tool that supports the various languages you use in your API development. Additionally, SAST is typically most impactful when it is run with highly targeted tests, which helps avoid the common compliant of high false positives for this type of testing.
How to Get Going with API Security Testing
Implementing a new type of testing in CI/CD can be intimidating.
The best way to get started is with running tests against a single, relatively simple API.
Once you have completed your first scan, dev-centric tooling will give you triaging capabilities so you are able to take action on the most critical vulnerabilities first. Many dev-centric platforms (including the one we are building here at StackHawk) mark findings based on criticality level like “High,” “Medium,” and “Low.” If you aren’t sure what a finding means or why it matters, you can often find cheat sheets linked in the platform you are using to help you broaden your security knowledge.
Once a vulnerability is identified, the scanner should give you the ability to recreate a finding with a cURL command so you can remediate any vulnerability on the spot.
Security is just another quality of a good API. These tools make it easy for developers that lack security expertise or don’t have access to a security team to make informed decisions around risk.
APIs represent a sizable and growing security threat to today’s businesses. No matter what type of API you are working with, you should have confidence that what you are releasing into prod is secure and critical data is protected. Testing APIs in prod is no longer good enough, and ensuring vulnerability protection in CI/CD is table stakes. Get going with vulnerability testing on a single API. Learn and iterate as you go to keep your app and your business protected.