The number and cost of data breaches have reached an all-time high. However, many of them can be averted when software developers avoid a few mistakes. In this article, Tom Hudson, security research tech lead, Detectify, discusses a few common API security mistakes developers can avoid.Â
The cost of data breaches has reached an all-time high – an average of $4.24 million per incident, a new IBM studyOpens a new window shows.Â
And among the largest incidents in the last five years, 56% were linked to some type of web application security vulnerability, according to another reportOpens a new window . Even worse, application issues took almost four times longer to discover compared with other intrusions.
Breaches cost organizations money, time, trouble, and reputational damage. And yet many could be averted if more software developers would adhere to three simple words:Â
Sanitize your inputs!
I’m certainly not here to wag my finger at developers. My roots are in software engineering, and I know developers have difficult jobs that get harder all the time in today’s world of accelerated development cycles.Â
But with more meticulous attention to code hygiene, developers can help themselves and their companies avoid major headaches later on.
Here are five common mistakes to be aware of:
1. Exposing Additional API Endpoints That Are Not Required for the Functionality of the Application
APIs are often rife with baggage, such as code left over from a previous version of the application. The code may no longer be needed, but its existence could still represent an exposure point for hackers.Â
For example, changes could be made in user information and privileges in the current version of the app but, those don’t get reflected in the older code that is no longer maintained.
Think of all this as a form of technical debt. The solution is to be very careful. When an app is developed, there should be a specific plan for how older code will be decommissioned. It’s also helpful to catalog all code; you need to have a view of everything that exists before you can secure it.
See More: DevSecOps: 5 Reasons to Integrate Security Into the Application Development Lifecycle
2. Enforcing Validation Through the API Rather Than the Client Application
Developers often build APIs for use exclusively in their applications without thinking they’ll end up publicly consumed. So during testing, let’s say, the API never sends any bad data and vulnerabilities aren’t uncovered. When the API does eventually end up in the application, there could be problems.
The answer is more rigorous testing of APIs in every potential deployment scenario, not just in a development vacuum.
3. Dropping the Ball on Authorization
It is all too common for developers to focus on checking whether a user is authenticated to access data while forgetting to determine whether they’re also allowed to access it. This can result in IDORsOpens a new window (insecure direct object references), caused when a database ID or filename is accidentally exposed to users as part of the URL parameter. The application fails to verify whether the user is authorized to access the app or data.
Again, better attention to hygiene can stop this. Make sure to structure the app in a way that data is guarded at the point where it is accessed. By using techniques such as model-view-controllerOpens a new window , the authorization check can be baked into the data access layer rather than the control layer.
See More: API Security: Ten Major API-Related Vulnerabilities and Ways to Address Them
4. CORS Misconfiguration
CORSOpens a new window (cross-origin resource sharing) delineates a way for client web applications loaded in one domain to interact with resources in a different one. It’s essentially a gating mechanism that regulates which domains are allowed to access an API. And it’s fairly easy to screw up.Â
A simple mistake such as forgetting to escape a dot in a regular expression could mean that while you meant to allow only www.example.comOpens a new window , wwwxexample.com is accidentally allowed too. Developers should be sure to check their work twice when executing CORS.
5. Path Traversal
OWASP defines a path traversal attack as one that “aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)†sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file systems, including application source code or configuration and critical system files.â€
The solution to thwarting path reversal attacks? Do I need to say it? Be extra careful out there, developers!
The good news about all five of these common errors is that all are avoidable by, to repeat my favorite mantra, sanitizing your inputs. So do that. It’s well worth the trouble.
Did you find this article helpful? Tell us what you think on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We’d be thrilled to hear from you.