8 Security Considerations for API Testing
8 Security Considerations for API Testing
API security is of paramount importance. In this article, we look at eight problem spots for specific aspects of API testing with impacts on security.
Join the DZone community and get the full member experience.Join For Free
How to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.
It seems like every day, we see reminders of the importance of thorough security testing from all areas of the software world. Security has become an especially critical consideration for APIs in recent years. Organizations rely on APIs to share and receive information — either from a third party or between internal applications — so the level of security between these applications is critical for anyone who uses them.
Earlier this year, SmartBear Software released the results of its State of API 2016 Report, which found that security is the top technology challenge teams that work with APIs would like to see solved in the years ahead.
Security isn't an easy problem to solve. It starts with selecting the right tools to test for API security vulnerabilities. But there are other API security testing considerations your team should be aware of, whether you develop or integrate with APIs.
Here are eight problem spots for specific aspects of application programming interface (API) testing with impacts on security:
1. Too-Accommodating Decoding Libraries
"CAPEC-80" illustrates how subtle security vulnerabilities can be. Unicode is a rich source of confusions, of course; English-speaking programmers often treat the world beyond ASCII as an afterthought. One immediate consequence: It comes as a surprise to find out that, for instance, the characters we see as MYBANK.COM might resolve to an entirely different and hostile site.
CAPEC-80 documents a distinct and thorny problem, one already observed in attacks against, among other applications, Microsoft's ISS server. Suppose an application immediately scans user input for dangerous sequences — an account name of "root," for instance, might be flagged as an error. The difficulty is that illegal values can be embedded in UTF-8, which results in a string decoding to "root" after it has already been validated.
Tests for such obscure errors are difficult to write. Generally, the best course is exploratory testing. In such cases, effective exploratory testing generally involves crafting problematic data and seeing whether the API under investigation unequivocally rejects them. While requests which go through don't necessarily prove a defect, they mark at least a questionable area that deserves pursuit.
CAPEC-71 is another among several variations of this same theme.
2. Test the Logger
Real-world services are under constant attack. Logging and good tactics for review of the logs are simple necessities. One consequence for testers: logging functionality is crucial. Anything a test program can do to verify logging is valuable.
Java architect Peter Verhas makes the point that logging for him is non-functional, and therefore we should "Never Test Logging." In this perspective, the point of this tip is that logging deserves to be a security requirement of every API, and therefore logging of this sort must be tested.
3. Make Sure All the Doors Are Locked
Testers with a focus on application functionality — most testers, that is — can easily overlook other-than-HTTP channels. All the ways to enter an API need attention. If an API supports a legacy portal through SOAP or FTP, for instance, it must be tested.
4. Think About Time
This one might better be labeled, "think about sessions." Conventional functional testing focuses on deterministic, correct results. Security-oriented API testing also needs to consider behaviors that are hard to replicate, especially around temporal sequences. In particular, APIs commonly authenticate throughout the mediation of tokens, which expire.
Does the API handle expiration correctly? Do sessions give proper access — enough, but not too much — to data after the renewal of an access authorization? Within a session, is the behavior of the API the same on the first and second use? This isn't a question about the idempotency of GET requests; that's a product specification matter. Does the API somehow change at the boundary of a session?
5. Test Developer Experience
User experience — and its testing — are recognized now as important. For APIs, developers are users, and their experience also deserves study.
6. Test the Documentation!
Crucial to developer experience is the documentation on which they rest their efforts. Published materials, of course, are the right reference for all testing, not internal product specifications. The importance for security is evident: developers who consume an API will code according to the documentation they read. To test the documentation against the publisher’s intent is essential.
An especially important form of documentation is all the sample coding provided to API users. An example program written in even one language coded in an insecure way is an invitation for every programmer working in that language to open the API up to abuse. Think of testing an API comprehensively: it’s not just the behavior of a specific endpoint, but everything–from content delivery network (CDN) to licensing agreement to support responders–that supports use of that API. Sample programs and related documentation influence API use enormously.
7. Test Errors
Error-handling is an important functional requirement, and always deserves attention, of course. Diagnostics that leak information attackers value are evident security mistakes.
More than that, though, error-handling remains poorly-standardized in REST APIs. The poverty of best practices in the area means that a lot of implementations are written for the first time: a recipe for security gaps. API error-handling merits proportionately more attention than error-handling for applications.
8. Challenge of Flexibility
The flexibility of REST — REpresentational State Transfer — introduces other specific technical challenges to testers, especially those sensitive to security. Think of a typical resource URI:/api/$VERSION/directory/UserID/$ID/Transactions/$DATE. The data are part of the URI; older testing tools handle this poorly. Even well-designed tools have difficulty expressing the whole range of inputs worth testing. Fuzz-based testing becomes difficult, if not intractable.
Adding to the complexity: Many valid URIs are generated dynamically, sometimes in client-side AJAX. All this flexibility and variation overwhelms vulnerability scanners and other tools based on lookups.
Make API Security a Top Priority
Security-pertinent API testing will remain incomplete and dynamic for a long time to come. Publishers need to analyze their own situation and vulnerabilities to decide the kind and intensity of testing which pay off for their biggest "hot spots."
Published at DZone with permission of Cameron Laird . See the original article here.
Opinions expressed by DZone contributors are their own.