Integrating API Security Into SDLC

You’re here, so you know how prevalent APIs are. And how vulnerable they can be.

Assuming APIs must be protected, when should this protection take place? In development or in production? Should you shift left or right or sit somewhere in the middle? What are the pros and cons of integrating API security into SDLC?

You’ll find the answers to these questions in the following sections. You’ll learn how taking timely security measures can dramatically improve your API development process as well as your entire security posture.

Dev vs. Sec: A False Dichotomy

Traditionally, the relationship between developers and security professionals has been plagued by opposition, conflict, and even animosity. Where does this tension come from?

A discussion about security in SDLC addressing seemingly “human, all too human” relationships may appear irrelevant and trivial.

However, businesses and organizations are not abstract entities. They’re human communities where relationships between groups of employees affect the overall culture, impact decision-making, and have severe security repercussions. Therefore, starting with the people is the best way to begin making security changes for the better.

Siloed Approach

Silo mentality is undoubtedly one of the causes of the tension between dev and sec. Questions like “Do developers care about security (at all)?” may appear legitimate to a cybersecurity professional used to working in a siloed environment. However, if anything, it just gives away deep-rooted assumptions and biases behind a widespread tribal culture.

This culture may be promoted by developers as well. If a dev team sees security professionals as a nuisance (secs tell them their code is flawed), an obstacle to efficient work (secs make them review code), and a hindrance to the realization of ultimate project goals (secs prevent them from meeting deadlines and budget restrictions or achieve quick time to market), then devs foster the same culture and, consequently, a siloed approach.

Conflict of Priorities

Another cause has to do with the conflict of priorities. Unfortunately, more often than not, in the business world, development priorities are different from security priorities. When an organization pushes for and incentivizes high productivity and speed, that’s what developers care for.

Security is not necessarily incompatible with dev productivity and speed. But typically, work pressure stemming from preoccupations with high productivity and speed is not an ally to security best practices, to put it mildly.

What Is The Solution?

The way out of this predicament is to:

• Break silos. Create an environment of partnership, trust, and collaboration, and let dev and sec teams work together from the outset of the software development life cycle.
• Provide systematic and continuous security training. You would be surprised how many API development security problems come down to insufficient or complete lack of security training. Refrain from expecting your developers to figure API security out on the fly: they already have a lot on their plates.
• Build a consistent, repeatable, and documented development process. In other words, create APIs in the same way every time and don’t let the process disappear with employee turnover: document it.
• Invest in API security tools. For instance, nonlegacy, automated API security solutions powered by machine learning can significantly decrease your SDLC workload and minimize API security risks.

Who Is Responsible for Security in API Development?

Some software industry experts talk roughly about three main requirements and corresponding historical periods in the software experience evolution:

• Functionality: In the early period, all that was required from an application was to do its job well.
• Aesthetics: The iPhone revolution brought a new essential requirement besides sheer functionality: aesthetics, that is, smooth user experience.
• Security: Today, countless security attacks and incidents later, a third essential requirement is security experience.

The meaning of this excursion into the evolution of software experience is to reinforce the tacit knowledge we all presumably have: security experience is so vital today that it can no longer be the responsibility of a single group of professionals.

Regarding API development and use, everyone is responsible for creating secure APIs and promoting the best API experience possible. That means developers must write code following security best practices, and security professionals must put proper safeguards in place, conduct regular API security testing, and perform fixes by teaming up with developers.

But the responsibility doesn’t end there. The initiative for implementing robust security policies must come from above the devs’ and secs’ pay grades. In that sense, senior leadership plays a unique role in this process.

When top management emphasizes and incentivizes secure development practices, approves an appropriate budget, and insists on consistent and structured development processes that integrate security across the board, that’s where the good things happen. Otherwise, a few years from now, we’ll still be stuck with the same OWASP API security Top 10 vulnerability exploits, wreaking havoc on businesses and organizations.

Shift-Left or Shift-Right?

In simple terms, shift-left includes security testing in a development environment. In contrast, shift-right encourages security testing in a production environment. Which one is better? And are they mutually exclusive at all?

The argument for shift-right emphasizes the importance of security testing in a realistic environment. It states that new, unforeseen problems occur when software goes live that cannot possibly be tested early in SDLC.

However, you’d be hard-pressed to find someone who disagrees with security testing being necessary (even long) after an API or a web application goes live. In that sense, shift-left doesn’t have to exclude the core motivation behind the shift-right methodology. The problem is that this reactive approach, promoted by shift-right, is insufficient by itself.

Integrating API security testing early in SDLC is a proactive approach that can save you time, money, and many headaches. It ensures your API is checked for code issues and security vulnerabilities when it is still reasonably easy and inexpensive to make corrections.

Moreover, in harmony with the shift-left perspective, organizations must factor in security before even developers start writing the first lines of code. They need to implement continuous security testing throughout the entire SDLC to guarantee that APIs are comprehensively examined and as secure as possible before reaching the first consumer.

How Shift-Left Can Help You Avoid a Security Disaster

To illustrate more vividly the point of the shift-left approach, we’ll look at an example of a major API security incident.

We assume no one likes Captain Hindsight—the know-it-all who gets everything right only after a disaster happens. Nonetheless, in cybersecurity, “lessons learned” is an important concept in incident response. It comes down to analyzing a security incident after it occurs to establish what precisely went wrong, what could’ve been done better, and what to do to avoid it next time.

In that light, let’s see what went wrong in the Optus case and how things could’ve gone differently had the company insisted on continuous security testing and applied shift-left practice.

The Optus Data Breach

Optus is a large telecommunications company in Australia that was the target of an API attack in 2022.

The attacker, known under the pseudonym “Optusdata,” gained access to sensitive data—ID and passport numbers in addition to names, physical addresses, and emails—of over 11 million Optus customers.

The source of the problems was an internal, non-production API left wide open to external users. The principal issue was that the API wasn’t even cataloged, which falls under the OWASP API9:2023 vulnerability—”Improper Inventory Management.”

The second issue was that the API lacked any authentication whatsoever, meaning anyone could access it. This shortcoming is a classic example of OWASP API2:2023—”Broken Authentication.”

The third problem was that the API included extremely weak identifiers. The IDs were incremental, meaning that if you knew only one identifier, say 123, you could access other accounts by adding (124) or subtracting (122) 1. This vulnerability is OWASP API1:2023—Broken Object Level Authorization (BOLA).

What Could’ve Optus Done to Prevent a Data Breach

Had Optus integrated API security into SDLC, it could’ve avoided this data breach. A suitable API security testing tool used early and continuously in the API development life cycle would’ve detected and warned against such a flagrant vulnerability as a complete absence of authentication.

The whole point of shift-left testing is that you use suitable techniques and tools that probe deeply into your API to find indicators of the most common and severe API security risks so you can apply easy fixes on time. You don’t wait for the Optusdatas of this world to show you the flaws of your APIs.

What we said about authentication applies to weak identifiers as well. Again, this is one of those most common weaknesses API security tests hunt for. The probability of thorough and regular testing missing it and up-to-the-minute API testing tools not alerting about it is next to impossible.

Regarding improper inventory management, even if Optus didn’t document all its APIs from the outset, continuous security testing would’ve resulted in alerts about a non-production API, a security liability. That would’ve helped the company take timely measures to strengthen the non-production API’s security or decommission the API altogether.

API Security Testing Tools

Manual and Automated Testing

Organizations should test APIs as often as new code is developed, period.

But this practice requires the right tools. Though indispensable, manual API security testing, such as expert penetration testing, is insufficient. The main reasons are that it is typically quite expensive and time-consuming.

To demonstrate the latter point, a manual penetration test of an API with 40 endpoints would take 154 hours. The problem is that, even then, we would be far from examining every input and sequence combination, potentially leaving out essential findings.

Since, in practice, the development pace and pentests are desynchronized, frequent automated security testing in CI/CD is where organizations should see the most benefits.

API security automation can keep pace with the frequent changes in software development and boost the overall work efficiency of DevSecOps teams. That’s especially true when the API tool is fueled by machine learning and large amounts of relevant data.

What Makes A Good API Security Testing Tool?

The following criteria are part of what you need to look for in an API sec tool:

• It must fit smoothly in your development and test infrastructure. If it disrupts the standard workflow and noticeably slows development speed, it’s not much of use.
• It must be designed with developers in mind.
• It must be able to detect the latest OWASP API Security Top 10 vulnerabilities.
• It must generate a report of detected vulnerabilities and weak points and suggest remediation.
• It must include API fuzzing.

DAST, SAST, and SCA

Not just any API security tool would do. An API gateway, a legacy API tool, or a web application security solution not even built for APIs would be of little help. Code scanners are not sufficient, too. Typically, they can’t catch the primary problems leading to breaches.

Generally, three types of API security solutions can be beneficial to SDLC:

• DAST (dynamic application security testing) emulates realistic attacks, searches for vulnerabilities and misconfigurations, and can discover zero days.
• SAST (static analysis security testing) tests source code issues and patterns in your code, but it must support the language your API is written in to do its job.
• SCA (software composition analysis) checks dependencies and compares the findings to a database of known vulnerabilities, helping you find only existing open-source vulnerabilities but not zero days and weaknesses specific to your API.

Since these three types of tools concentrate on different aspects of APIs, they can complement each other. That means it’s ideal to use them together if your budget allows it and you don’t already stagger under the burden of an acute tool sprawl. Otherwise, choose the one that makes the most sense in your situation, considering, among others, the criteria from the previous subsection.

Conclusion

For lack of better words, we’ll cite a small part of the DevSecOps Manifesto:

“We won’t simply rely on scanners and reports to make code better. We will attack products and services like an outsider to help you defend what you’ve created. We will learn the loopholes, look for weaknesses, and we will work with you to provide remediation actions instead of long lists of problems for you to solve on your own.

We will not wait for our organizations to fall victim to mistakes and attackers. We will not settle for finding what is already known; instead, we will look for anomalies yet to be detected.”

These words summarize how you should see integrating API security into SDLC and what attitude you should look for in an API security testing vendor.

Equixly is an automated API security testing tool that lets you find your application’s business logic vulnerabilities, locate edge cases, and unearth blind spots.

Contact us to learn how it can help you integrate API security into SDLC.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.