When it comes to API security, no integration is 100% safe. Breaches meet the news day after day. Vulnerable connections continue to expose private data, costing companies millions of dollars in repairs and resulting in terrible PR.

To answer this crisis, our 2019 Platform Summit will bring together some of the world’s top experts on API security. To kick start conversation before the event, we’ve assembled a panel of expert security speakers to cover the most pressing security topics in the API space today.

For this article we’ve interviewed Jacob Ideskog, Solution Architect & Identity Specialist at Curity, Keith Casey, API Problem Solver at Okta, David Stewart, CEO & Co-Founder of Critical Blue, and Michał Trojanowski, Senior Software Developer at Allegro.pl. We’ve asked each to describe the top threats facing APIs, and what best practices providers can use to mitigate them. We’ll also uncover some security anti-patterns and peek into the future evolution of security in 2020 and beyond.

Current API Threats

APIs are powerful doorways to user data. They channel information that, if stolen, could have drastic ramifications. With the ever-evolving landscape of vulnerabilities, which stick out as prime areas for greater security emphasis?

User Privacy

Too often, private secrets, keys, or cloud storage passwords are leaked to nefarious actors. According to Jacob Ideskog, “stealing a user identity is more than just the credentials.” User privacy is Ideskog’s top concern.

“Not only are credentials important to keep close to heart, but also that the user’s privacy is important,” says Ideskog. Alluding to recent GDPR legislation, Ideskog notes added pressure for API-based companies to protect user privacy with vigilance.

Mass Overload Attacks

Keith Casey cites the growing cost associated with stolen data across verticals. “We have healthcare, financial, personal, and a variety of other kinds of information that are damaging to people and groups if stolen,” says Casey.

Denial of service attacks or massive transaction costs for a target is just as valuable for hackers to exploit. Thus, to Casey, consumption-based APIs without strict rate limits are most vulnerable.

Knowledge Gap

David Stewart acknowledges that threats are always evolving, and as such, require much financial investment to retain security (one way to outpace attackers). With today’s integrated platforms, a single link in the chain can have a cascading effect across an entire platform.

“As this is a time of explosive growth, many of the threats come from poor education, poor implementation, naivety as to how fast and deep you lose control and data once a hack succeeds,” says Stewart.

Testing the Unexpected

Avoiding exploits requires comprehensive testing of “API usage outside their expected usage patterns,” says Stewart. Trojanowski echoes this sentiment, citing how application security is a “constant process of trying to find solutions to ever evolving threats.”

Trojanowski notices how APIs are coming to market vulnerable to even known vectors like CSRF or XSS. Other threats offer little to no current solution, such as “situations where the attacker manages to impersonate another user, or where a malicious actor gains legitimate access to an API but abuses the access,” points out Trojanowski.

Trojanowski notes how utilizing machine learning to monitor API activity for such misuse may be a future volution for API security.

Security Best Practices

Knowing the threats out there, what can API providers do to better arm themselves? In short, our panel summarized API security best practices as such:

• Don’t build your own system
• Build with security from the start
• Continually educate and share knowledge between teams
• Read up and follow the standards

Let’s dig into the details of what these best practices entail.

Don’t Build Your Own System

According to Ideskog, the #1 thing to remember with security is that it is extremely difficult to build your own security system. In fact, building the wheel again would go against the philosophy for most API based SaaS, PaaS, and IaaS.

“The devil is in the details when it comes to security, which means that it’s a ”weak link“ problem,” says Ideskog. “A few small bugs in different parts of the system can open up a large vulnerability.”

Security can’t be an afterthought, and cutting corners can be detrimental. To Ideskog, this equates to reviewing the standards religiously, and not building your own security system.

Casey also believes that building your own system is not the correct strategy. “Stick to standards,” says Casey. “Don’t build your own encryption, protocols, or encoding schemes when there are numerous proven options available.”

Security Comes First

Once viewed only as a “tool for a handful of internal ”trusted“ users,” Casey describes how many APIs were first created within safe internal environments. Later, the same software was externalized to other teams, partners, customers, and public users,

Though business use cases may have changed, the problem is developer processed have remained static. As Casey describes, either there is a reluctance to change authentication schemes as it may break systems, or, teams simply aren’t thinking about it.

Casey stresses that we must “re-evaluate our initial security assumptions” to place security far more ahead in the development lifecycle. For Casey, this re-evaluation entails:

• Realizing that “obscurity is never security.” Black hats will always find your API.
• “Acknowledge that your tools and tactics are different and consider how your frameworks, API gateways, and infrastructure can protect you inherently.”
• “Realize that even with “unlimited” APIs, requiring authentication and authorization gives you control and a way to communicate with your users.”

Common Anti-Patterns

What are companies commonly doing wrong when it comes to API security? Perhaps the most common mistake our panel witnesses is not following standards.

“There are plenty of resources available out there: resources shared by OWASP, RFCs describing standards, RFC describing best security practices — to name a few,” says Tojanawski. “Still I think many companies do not pay much attention to them, especially the teams which are focused on delivering the APIs.”

Tojanawski and Stewart are quick to mention the OWASP top 10 list, which identifies the 10 most seen application vulnerabilities as such:

1. Injection
2. Broken Authentication
3. Sensitive data exposure
4. XML External Entities (XXE)
5. Broken Access control
6. Security misconfigurations
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with known vulnerabilities
10. Insufficient logging and monitoring

Stewart identifies other anti-patterns that are too common throughout API providers:

1. Publicly exposed secrets. “They are often easy to find in code, stored in git repos, logged as part of API call logs,” says Stewart.
2. Strong user authentication without strong authorization
3. Not identifying the source of the API call
4. Lack or loose security controls
5. Incompatibility or lack of oversight when using multiple security tools
6. Poor securing of communication channels

In terms of best practices, Stewart emphasizes “continual education, and a cross-functional security audit with a strong incentive to do security right, right from the start.” Ideskog similarly recommends continued education: “read up on the security standards OAuth and OpenID Connect.”

Education is the first step. Sharing API security knowledge between teams is the second. API developers especially must be aware they carry new security responsibility burdens.

“Of course it is useful, especially in a bigger organization, to have an individual or a team dedicated to security topics, but knowledge of API security should be spread among your developer teams,” says Trojanowski.

Future Evolution: API Security In 2020

How are security vulnerabilities changing and evolving? How will design change to meet these new hurdles? All our panel respondents agree on one thing; attacks will become more sophisticated as time progresses.

Looking to the future, Ideskog foresees increased complexity in attack vectors, and more conniving tactics, which will increase time to detect. This is forcing more resilient systems with impeccable design patterns.

“The attacks are becoming more sophisticated so I think that it will be harder and harder to detect that an attack is ongoing,” says Ideskog. “Putting a firewall or a gateway in front of the APIs will not be enough.”

Casey agrees that sophisticated attacks require new design moves and architectural repositioning. The API economy has matured quite a bit. Now, so must security along the development process.

“I think API vulnerabilities are only going to get worse before they get better,” says Casey. “We’ve spent 10 years building amazing APIs that power mobile apps, microservices, and deep integrations with partners but we built those in a time when APIs weren’t targeted. Now they are”.

APIs are now valuable, prime targets. Case notes that criminals can use things like hypermedia, public documentation, and live sandboxes to ascertain deep API knowledge. While those tools are crucial for improving developer experience, API providers must balance both outward information and access control with greater care than ever before.

In addition to increased “sophistication and speed of vulnerability discovery by attackers,” Stewart predicts a potential shift from high-value targets to more “less-value-per attack targets.” This could be due to the rise of expensive security armaments deterring attackers away from high-value targets.

Lastly, Trojanowski expects more of the same — a high number of vulnerabilities and omnipresent bad actors. Perhaps that is due to architectural trends which displace teams:

“In a distributed environment, where you have an API consisting of different microservices created by different teams, I’m afraid the vulnerabilities are bound to be repeated,” says Trojanowski.

Platform Summit and Beyond

It’s hard to predict the future, but from what our panelists can gather, attackers will continue to find nuanced methods of penetrating systems. APIs are by no means out of the line of fire.

Thankfully, at this year’s Platform Summit, all our panelists will be sharing their insights on how to properly defend. To get a teaser of their talks, we asked each panelist how their sessions will be addressing the top API security threats:

Attend Jacob Ideskog’s pre-conference workshop on OAuth and OpenID Connect in Practice
I will be talking about how critical identity data can be pulled out of the API and made more secure. How to identify this data and why it matters who provides it.

Attend Keith Casey’s session How to Build an Effective API Security Strategy
In my session, I walk through the mindset on how we got here, the implications of our collective mistakes, and layout some concrete steps to improve API security. We can’t prevent every attack but we can mitigate the damage and consequences for us, our organizations, and our careers.

Attend David Stewart’s session API Abuse – The Anatomy of an Attack
My presentation will describe what an attack against an API looks and feels like. People often expect it to be a bulldozer approach where massive amounts of traffic hammer against your front door. That can happen, but it’s much more likely that attack will be subtle and at low frequency … To beat the enemy, you first need to understand them. This is the theme of my talk.

Attend Michał Trojanowski’s talk When Basic OAuth Is Not Enough:
I would like people to notice the different RFCs that are being created for the OAuth framework which help to make it even more secure and to broaden the functionalities it originally provided. I myself have learned a lot about security issues of OAuth by reading the different extensions to the RFC OAuth. I would also like to raise awareness of the features of OAuth people use, and whether they’re used in the best possible way. This way I hope APIs will be less vulnerable to attack vectors targeting OAuth features.

The benefits of conferences cannot be understated. But don’t take it from me. According to Trojanowski, “being physically at a conference also gives you the ability of networking and gaining some crucial knowledge straight from the people you meet.”

Tickets to the Platform Summit 2019 can be purchased here.