API Security Awareness
The awareness of the need for API Security is on the rise. There are a couple of good sources, such as APIsecurity.io, that have been hammering to raise awareness for some time. More established sources, such as OWASP are now following suit. As a result, API Security recently got its own vulnerability Top 10. Even Gartner has published a research note on the topic.
I know, security is important, but also a no-win proposition, and you’ve got so many other things on your mind already. So, before you switch to something else, please know there is a solution to the problem. It is actually quite easy to harden your APIs, if you’re willing to take the right approach. Moreover, I’m talking about a solution your developers will be eager to embrace. Let me explain.
Prevent and Detect
Everybody knows there are two sides to securing your access – prevention and detection. With APIs, this is no different. To prevent, for instance, you can audit the specification of an API.
- Are there no personal identifiers included in the API specification that should rather go in a token, so they cannot be tampered with?
- Has proper authentication been applied?
- Are all input messages defensively specified?
Additionally, you can test the output of your APIs.
- Do the replies comply to the contract?
- Is there no sensitive data in replies?
- Is there no unnecessary data in error messages?
You get the idea. If you’re looking for more clues, do visit the OWASP TOP 10 API threats.
The detection part also has several tactics. Some threats can be tackled with a regular API Gateway, such as bot protection, throttling on message size and amount of messages, and cross-origin resource sharing. But some are more subtle. What about sending malicious input, designed only to bring your backends down? Are you sure your developers have all the validations in place to keep your systems healthy? Have you tested they can stand the strain an attacker may put on them? I don’t want to scare you, but there’s a lot going on out there.
I guess it’s time I’m going to reveal my well-kept secret to you. I’m offering you a relatively straightforward way to secure your APIs. No kidding. Read on.
If you think about it, there’s only one way to make APIs testable and protectable. They have to be specific and explicit. It's not enough to specify a number type, you have to give a range of acceptable values. And with every string, think about values you accept. You know, minimum length, maximum length, no special characters. Simple things that you can easily catch in a regular expression. Did you know that the Open API Specification allows you to specify a regex? Additionally, give your arrays a thought. You can be sure that this is one of the first areas an attacker will focus on. How many items do you expect? Have you strongly typed your items?
What about your response definitions? They also require some thought. You want to ensure you're not sending out any unwanted data, but to assess that, you need a formal schema definition with every response body. How else can you know what to expect?
With a generously defined API, conform industry best practices, you unlock a powerful new potential. First of all, attackers will think twice when they encounter a fully specified API definition. After all, you evoke a sense of carefulness. That will likely deter all but the most targeted attacks. But there’s more. With such a definition, you can generate automated tests that will verify if your backend system is properly built. Does it react properly when it gets improper input? Does it send the expected return? Or is there a vulnerability that hasn’t been caught before? Also, you can validate all incoming API requests before they hit your precious backends. It’s always so much better to block any unwanted guests at the perimeter. Simply don’t let them in, so they can do no harm.
So, it turns out that both prevention and detection benefit from a proper API definition. Killing two birds with one stone. But how do you get your developers to put so much work into an API definition? Good question. My answer? Just make it fun! And I know a way how to do exactly that.
Please allow me to introduce 42Crunch. You probably read it here first. It’s a cool startup. They are not only the brains behind APIsecurity.io. They offer API Security support throughout the API lifecycle. One of the things to like about this tool suite is the thought that went into scoring your APIs. Because this is where the fun actually starts. The audit tool will score your API definition against a set of best practices. It gives you an overall score, and it pinpoints critical errors. Obviously, in your CI/CD pipeline, you want to block an API with critical errors in its definition. Perhaps you want a minimum score. Unsurprisingly, your developers are going to be eager to beat the system, and to get it first time right. Just for fun.
Subsequently, now you have an appropriately defined API, you can do a decent scan to establish if your API lives up to its contract. You probably guessed it, once again you get a nice report with a score out of the conformance scan. Shame on the developer who doesn’t pass this test. Again, any critical error needs to be fixed before you promote your API to production status. If you want, you can publish the results right on your CI/CD dashboard. Anyhow, make it part of the conversation your developers are having.
Boy, these tools, when used properly, really help a lot to develop a great API. All you have left to do, for maximum security, is to enforce your API contract. To keep the dark forces out of your systems. That’s where the protection tool comes in. You can generate this from your CI/CD pipeline as well, putting your developers in charge in the process. You see? The entire life cycle from design, through test, all the way to secure production is covered here. And what’s perhaps the best of all is the tight integration with the WSO2 API Publishing and Management Portal. Embedding secure API design into your development cycle has never been easier.
Don’t forget to add some healthy competition into the mix. This is your magic dust. Why not reward your best developer with some praise? Maybe make this something recurring during a retrospective, or a quarterly meeting. Just make it fun. You probably know the old saying that you cannot manage what you do not measure. Well, now you can finally measure the quality of your API, so no more excuses to not start managing it right away.
As always, we’re there to help you out hardening your APIs, if needed. And we love to engage with fun.