API Security is a hot topic! The security aspects of APIs surfaced 1-2 years ago big time. Let this post be the touch into this delicate subject about which I have only little practical experience. I need to engage developers to this topic and make more practically oriented post a bit later. I’ll throw in here some thoughts on the subject.

Building secure APIs is also preventing API consumers to create security risks or leak private data. Take the security as a build-in feature, a part of the DX rather than something heavy and separate thing - an add-on. Great security is taken into account already in system design phase.

According to Nordic APIs the security threats “2020” are, some picked here:

Common Anti-Patterns and OWASP top 10

The Open Web Application Security Project (OWASP) is an online community that produces freely-available articles, methodologies, documentation, tools, and technologies in the field of web application security. OWASP top 10 list, which identifies the 10 most seen application vulnerabilities as such:

API security related antipatterns are:

Automated testing

Everyone wants to automate all that is possible at the moment. That’s what we do at Platform of Trust as well. It brings speed and saves costs. Possibly even occasionally reduces bugs and mistakes. Doing automated security testing for APIs is probably not a subject for which you would not find some solutions. I have hard time believing that you can get really good coverage of security tests with just automation. Keep in mind that all it takes is just one big hack and your service or platform is most likely doomed or at least nearly that. You might survive a security flaw causing privacy leaks and alike but I would not count on that.

White hat hackers

If you have not heard about white hat hackers yet, you should digg into the subject now. A white hat hacker is a computer security specialist who breaks into protected systems and networks to test and asses their security. White hat hackers use their skills to improve security by exposing vulnerabilities before malicious hackers (known as black hat hackers) can detect and exploit them. Although the methods used are similar, if not identical, to those employed by malicious hackers, white hat hackers have permission to employ them against the organization that has hired them.

But you want to involve people (hackers are people too) in the testing. The hackers are ….drum roll…developers! Hackers are not some subhuman species but they are developers, often highly talented and focused (security) developers. You want their experience and skills as well as creativity. AI possibly can simulate human hacker to some extent at some day, but our ability to mix logic and random intuition is unique. That is hard to beat. And those skills are needed if you want to hack a system. The most obvious holes should be caught with automated tests.

Using hackers in enhancing the security is not peanuts business. White hat hackers in HackerOne service earned over $19 million in bounties 2018, a single hacker passed more than $1 million in earnings. Hackers can make a good income by putting the skills in good rather than bad/criminal activities. Some more hackerone stats:

Where are the hackers in HackerOne coming from? Not a surprise that Russia is one significant location. Indians probably see the bounties as lucrative way to earn money and they have huge population, so hackers might grow on trees. Or India based hackers are so plenty that they form a hacker swarm and thus raise in the report.

According to HackerOne money is not the only reason to participate:

APIs are not the biggest part of the systems to hack. Websites are the most common target, but still 6,8% of the cases are API related.

Hire a hacker…or buy access to hackers

Mårten Mickos kickstarted HackerOne service to offer white hat hackers to test and asses system security. In other words hackers for contract. I’ve used the Finnish counterpart of HackerOne, Hackr.fi, once when I was Product Owner of national authentication system for K12 education in Finland. We launched a campaign with Hackr.fi service and gained information on possible attack vectors and flaws in permissions in filesystem, but no serious (?) security holes were found.

Run campaings as a subscription mode?

Of course hiring hackers to fiddle with your service (API or something else) takes time. If I recall corretly the period we had the campaign open was 6 months. So it’s obvious that you don’t do this kind of security testing after every bug fix or minor update. The length of the campaign (or slowness) makes it hard to use these services. You might have time for this kind of operation for example when getting ready to launch new version of the API. Optimum would be to have constantly open campaign going on, but that is not something I’ve seen yet. Keep the moneybag there, let the hackers find the holes and reward them. Keep the campaign on like a subscription plan.

Some more to read from 100 Days DX