Do you have APIs? How do you test them?

Application Program Interfaces (APIs) have changed in nature in recent years and are increasingly (and sometimes inadvertently) being made available to users of web services, the “Apps” (applications) on mobile devices, and internally for the web application to talk to the back end processing and database.

30 years ago an API was simply a DLL (Dynamic linked library) of code that fulfilled all the specialized operations needed to provide the functionality of an application. These days it is the middle layer between the user and the core application functionality, and it is being provided as JSON or XML data using HTTP calls over publicly visible SOAP or REST interfaces.

Typically an API receives parameters and actions from the application to operate directly on the server. Without adequate authentication, authorization, and session controls, the wrong people may gain access to data they should not have access to. With every browser now having the ‘developer tools’ available to enable any user to look at the code and transaction parameters being sent and received over the internet and then manipulate the parameters, you want to be testing your APIs before the hackers do.

Many high-profile breaches (with high record loss counts) in companies such as Facebook, Twitter, Tesla, and Capital One bank have resulted from APIs not having enough protection, or employing easily guessed and fuzzed parameters, along with inadequate authentication for each transaction, overall session control. This has become such a big problem that OWASP (The Open Web Application Security Project) has published a top 10 list of flaws for APIs separate from its signature list of application flaws.

Regular application testing tends to take three tacks, 

1. Static testing (SAST): where a source code scanner looks for type mismatches, function calls missing parameters, failure to check for return codes, possible stack overflow, and never executed code. 
2. Dynamic testing (DAST): Where a tool executes the major branches of the code to ensure that all the correct responses are received, error inputs are recovered from gracefully, and storage and logging occur the way they were intended to.
3. Penetration testing: A threat surface evaluation is performed and a person attempts to compromise the functioning of the program to cause it to reveal more data than it should.

API testing adds another layer, in a way that transcends SAST/DAST, firewall rules, IDS/IPS, and changes traditional pen-testing. 10 API end-points potentially exposed to 100 categories of flaws can easily expand to over 1000 tests that need to be performed.

A comprehensive test should be able to take your API definition files such as Swagger output, RAML, or OAS definitions, break that file into its component parts, and then automatically create credentialed and uncredentialed tests in all of the 100 different categories to ensure that your API is not susceptible to any of the OWASP top 10 API flaws, and more. 

Especially if your API allows for account creation and role manipulation, you need to know that it is secure before a hacker finds out for you.

A test using a set of temporary credentials for at least two peers, and ideally each of the multiple roles that can access the API, can give insight into whether UserA could access UserB’s data by manipulating API parameters or credentials, for instance.

Internal APIs are not immune to business logic flaws or other OWASP top 10 API faults, and it is well known that insider risks are the most damaging, so you want to test internal APIs as well as the externally visible ones.

FedRamp calls out API testing as part of the overall requirements for an application suite to release to production. PCI DSS does not specifically call out API testing, but such tests can and must be covered as part of the 6.3 - 6.6 requirements to build and test secure applications and by extension 11.3 penetration testing.

Just like application testing, APIs still need both vulnerability testing (all the time) and penetration testing. The mantra is still true that it costs 10 times as much to repair a flaw as the application progresses through each stage of development and production. Therefore the best place to integrate an API test is during the SDLC. You don’t want hackers finding the flaws for you. So don’t consider that application testing is complete until you’ve tested the APIs too.

Don’t assume your regular pen testers are good at testing APIs, this is so far a new and specialized niche. Make sure to call out API testing explicitly in the scope of your next pen test and validate that your test team is qualified to do this type of testing. Also, don’t use regular application testing tools like Burp suite and assume that they are going to fully test an API. 

You should also consider APIs separately from their web application in your annual risk assessments.

It’s time to take API risk seriously. With pandemic lockdowns and criminals working hard to breach everything they can, API flaws are a relatively new target and increasingly common vector for how people get breached. Expect your auditor to be focussing on them (and if they don’t, ask them why they are not).

Truvantis can offer advice on all aspects of API and other application development and deployment issues.