The Checkmarx AppSec Program Methodology and Assessment (APMA) framework helps enterprises adopt a risk-based scanning and remediation strategy. It integrates an understanding of the risk surface, through the creation of a business application inventory with suitable risk ratings, coupled with effective preset management and application onboarding.  

After conducting more than 100 assessments of enterprises around the world, we have come up with five tips to build an impactful AppSec program.  

1. Risk Rank Your Business Application Inventory 

One of the pillars of effective application security is understanding your risk profile. Not all applications are created equal. A risk-rated inventory is targeted and efficient way to allocate security resources to an application proportionate to its criticality. 

Organizations must keep a detailed inventory that takes into consideration factors like whether it’s internal- or external-facing, data sensitivity, and application criticality. This becomes the backbone for informed decision-making, allowing development teams to prioritize their effort on the most critical applications. Organizations that do not have a business application inventory tend to have with poor tool deployment, affecting the overall developer experience. 

How do organizations stack up? 

• 72% of assessed organizations don’t have a risk rated inventory  
• 65% of those assessed organizations that didn’t have a risk rated inventory either did not have their scan results reviewed or did not have developers execute a remediation process.  
• 75% of assessed organizations that have a low business application inventory maturity also have only rolled out AppSec testing tools for less than 50% of business applications. 

2. Optimize Presets for Targeted Scanning 

Organizations have different goals — compliance, focusing on high-risk vulnerabilities or taking a comprehensive look at all potential risks. AppSec solutions should be tailored to the goals to improve result fidelity and developer experience. 

50% of assessed customers have not taken the first step to select the preset that aligns with their security strategy. 

Applying a risk-based security strategy involves preset optimization. While default presets are comprehensive, a “boil the ocean” approach can overwhelm development teams and lead to too much noise. The result may lead to developers fixing non-exploitable vulnerabilities, rather than the critical vulnerabilities that pose a significant security risk. The volume of security testing results, coupled with existing workloads, may lead to frustration and resistance.  

Organizations should adapt their scanning strategies according to their risk tolerance and business goals. Checkmarx advocates a three-step preset reset plan to mitigate result fatigue and enhance developer adoption: 

• Step 1 – Narrow the preset: Introduce narrow aperture presets. 
• Step 2 – Identify and tune outlier queries: Iteratively search for outlier query results, customizing them for best results. 
• Step 3 – Focus on critical applications: Channel efforts towards critical applications, deepening SAST scanning, and query customization. 

A measured approach to preset customization significantly affects the long-term satisfaction and experience of development teams. 

3. Onboard Applications in a Structured Manner to Create a Baseline 

Developing a mature application onboarding process is critical to consistently review and remediate results. The onboarding process, encompassing initial scanning, result review, and SDLC integration, sets the stage for application security testing. It ensures that development teams are familiar with security testing processes. 

This process includes tuning checks, rules, and queries, optimizing them for the specific application’s architecture. A security architecture assessment adds another layer of refinement. Regular reviews ensure continuous alignment with evolving application architectures. 

Why is this important? Here’s some real-world data: 

• Only 21% of assessed customers have a structured process to onboard applications. 
• 75% of assessed customers with mature triage and optimization process review results on a consistent basis. 20% of them even break builds when processes are violated. 
• Customers who have a mature triage and optimization process have a 10x better policy enforcement rate. 

4.  Take Advantage of Automation and Integration for Continuous Security Testing 

Automation is key. Integrating automated security testing tools into the development workflow streamlines processes, reduces manual efforts, and ensures consistent results. Organizations with more mature AppSec programs automate security testing to enable more successful review and remediation processes. 

Automated tools offer real-time feedback, enabling issues to be resolved early in the development process. This prevents vulnerabilities from escalating. Developers receive immediate feedback when they commit changes, addressing security issues when they are most attuned to the code, fostering a more agile and secure development process. 

Organizations that automate the testing process reduce friction within their SDLC process, therefore improving their developer experience. 

Lack of automation has a direct impact on result review and remediation. 

• 64% of assessed customers with a high level of scan automation were more likely to have development teams that reviewed results and remediated vulnerabilities. 
• 77% of assessed customers that didn’t have scan automation also had had development teams that didn’t review results or remediate vulnerabilities. 

5. Educate Stakeholders about AppSec  

The success of any AppSec program is tied to the education given to stakeholders. Developer training programs that emphasize secure coding practices, coupled with comprehensive documentation  and code samples, improve the maturity of AppSec practices. Yet, 39% of assessed customers have no education and guidance strategy and only 32% of assessed customers have implemented higher maturity education and guidance strategy. 

Education should be tailored to four key roles: 

• AppSec management 
• AppSec experts/champions 
• Developers 
• Operations 

Organizations that have a comprehensive education and guidance component see a 25x-30x higher rate of results review and remediation process execution by development teams. 

The APMA Framework: A Roadmap to Enhance Developer Experience 

When the speed of development is non-negotiable, integrating robust application security measures is a must. The APMA framework, distilled from real-world assessments, provides a roadmap for organizations to not only secure their applications but also enhance the developer experience. As organizations embark on this journey, they not only fortify their defenses but also foster a culture of security that resonates throughout DevOps and the SDLC. 

Organizations can get started with APMA by taking the free digital assessment. In just a few minutes, they can obtain actionable recommendations to get started on their AppSec journey. Larger  enterprises can contact us for the full assessment. 

This leads to Denial of Service (DOS) for those who install “everything, “which causes issues like storage space exhaustion and disruptions in build pipelines.

The creators of the “everything” package have published over 3000 sub-packages. These sub-packages are designed to split the dependencies into chunks and to depend on all publicly available NPM registry packages. 

The creators have also registered the domain https://everything.npm.lol/. On this website, they showcase the ensuing chaos and incorporate a famous meme from The Elder Scrolls V: Skyrim, adding an extra layer of humor or mockery to the situation.

Not the first time this has happened

A year ago, we encountered a situation with the package “no-one-left-behind” by Zalastax. This  package depended on every publicly available npm package, creating an intricate web of dependencies. Despite being removed by the npm security team, a new development emerged on Jan 28th, 2023. Over 33,000 packages under the scope “infinitebrahmanuniverse,” prefixed with “nolb-,” surfaced as sub-packages of “no-one-left-behind.”

The downsides of these trolls

Imagine you did an experiment, published a package to NPM and now you want to remove your NPM package. You can’t do it if other packages are using it. The problem is, since “everything” relies on every package (including yours), your package gets stuck, and there’s some unknown package preventing you from removing it.

An attempt to delete the packages

It doesn’t seem PatrickJS realized the headache his troll would cause to some users. Two days after the prank packages were published, he created an issue and shared that he is unable to delete the packages since the NPM mechanism prevents deletion of published packages once they are being used by other projects and calls for help from NPM support team. 

Summary

This act of digital mischief by PatrickJS echoes past incidents, highlighting ongoing challenges in package management and the cascading effects of dependencies within the NPM ecosystem. The situation underlines the comedic yet serious consequences of such pranks in the developer community.

As a result, security and development teams are focusing on how to best secure their growing API footprint. With many API security solutions on the market, it can be hard to determine which one is the right choice for your organization. Here is a quick checklist to leverage during your evaluations: 

1. Can it find all your APIs?

For any API security solution, its ability to secure APIs relies on knowing what APIs exist. Many solutions require security teams to upload API documentation, such as Swagger or RAML files, which define an API. This approach relies on developers properly documenting their APIs, uploading documentation to a common repository (such as Postman), and keeping documentation up to date as the APIs evolve. 

Other solutions discover APIs by watching where traffic goes, by monitoring traffic on a CDN or integrating with hardware appliances, including API gateways, web application firewalls (WAFs), or load balancers, where API traffic flows. This requires the AppSec team knowing all the network chokepoints that API traffic flows through, which isn’t always easy in a changing network environment. Not only that, but it is easy to miss traffic to APIs that are publicly exposed but see little traffic.

Checkmarx starts by scanning your application source code, so we can discover all the APIs in your application. This approach does not require APIs to be properly documented (although that’s still good development hygiene), and can be done without having to integrate with your network infrastructure.

2. What about shadow and zombie APIs?

Shadow and zombie APIs are a big challenge with most API security solutions. A shadow API is another name for an undocumented API. Traditional API security solutions, such as WAFs and API gateways, require API documentation to configure protection – they cannot protect what they don’t know. AppSec teams are often not aware of these APIs and refer to these as shadow APIs.

A zombie API is an API that has been abandoned or forgotten. Organizations can inadvertently create zombie APIs when creating new versions of an API. In this situation, organizations often choose to leave the original API in production for a limited time, to ease the migration of users and traffic to the new API. However, they might forget to decommission it after the migration. Zombie APIs may see little traffic after users have been migrated but remain exposed for attackers to find.

Checkmarx helps you identify shadow and zombie APIs by comparing your global API inventory – the full list of APIs discovered in your application source code – with API documentation provided by your developers. This allows us to identify gaps in documentation and work with your developers to close them.

3. Discovering APIs and identifying vulnerabilities

Discovery is only the first step when it comes to securing your APIs. Once you’ve built a full inventory of your APIs, the next step is to identify what vulnerabilities they may have. Runtime solutions such as API gateways and WAFs can tell you what types of attack traffic may be targeting your APIs (and hopefully block it), but they can’t tell you if the targeted APIs are vulnerable to detected (or undetected) attack traffic in the first place.

Checkmarx layers our API Security solution on top of Static Application Security Testing (SAST) to not only discover APIs, but also identify vulnerabilities in your application source code and connect them to individual APIs. Checkmarx provides an API-centric view into your vulnerabilities, allowing you to see a breakdown of detected vulnerabilities by API, so you can focus your efforts on securing your most critical APIs.

4. Find and fix vulnerabilities – earlier in the SDLC

The cost to fix a software problem discovered in production is 100x more costly than if fixed in the design phase, and 15x more than during the coding phase. This provides a powerful incentive to find and fix vulnerabilities as early in the software development lifecycle (SDLC) as possible. However, most API security solutions focus on APIs already deployed in production environments, where identified vulnerabilities are the costliest to fix.

Because Checkmarx discovers APIs and identifies vulnerabilities in your application source code, we help organizations fix vulnerabilities in the coding phase where they can be remediated faster, with less disruption, and at lower cost. Checkmarx also identifies data discrepancies between API documentation and source code to address both improperly coded APIs as well as API drift. And finally, Checkmarx provides an API change log to help you understand the full history of changes to an API so you can understand how risks were introduced over its lifecycle.

5. Standalone solution vs AppSec platform

Modern applications continue to evolve, with greater complexity and more pieces to secure that need more security tools to secure them. Application security teams have more tools than they can properly manage, an issue that is magnified when every tool needs to be managed separately. 

Consider API security solutions that simply discover APIs in production environments. Arming AppSec teams with that information is a good start, but those APIs must still be tested to identify vulnerabilities – either the live API with a Dynamic Application Security Testing (DAST) tool or the source code with a SAST tool. And even if the solution identifies vulnerabilities in an API, now AppSec teams must manually correlate identified vulnerabilities with those identified by other tools.

Checkmarx approaches API security as a part of a more holistic approach to application security. Our Checkmarx Oneplatform provides organizations with all of the tools needed to secure every part of the application, including not just SAST, DAST, and API security, but also Software Composition Analysis (SCA), Software Supply Chain Security (SSCS), Container Security, and IaC Security. 

6. Automate as part of. your DevSecOps pipeline

As development becomes more agile, development teams are becoming more fragmented – often by design. This allows different developers or teams of developers to work on different parts of an application independently of each other. This also can make it more difficult for AppSec teams to stay on top of changes to the application. In this type of development environment, AppSec teams know that the only way to ensure security checks always take place is to automate scans at different parts of their DevSecOps pipeline. 

With Checkmarx One, integrating with any tool in the SDLC, from software repos to build tools, is as simple as a few clicks of the button. Checkmarx integrates with the broadest range of SDLC tools in the industry and, as a unified AppSec platform, integrates all of our AppSec solutions with any SDLC with a single set of integrations.

7. Who’s responsible for fixing?

AppSec teams know that their job is to find security vulnerabilities – but not fix them. AppSec teams don’t touch application code and need development teams to fix the vulnerabilities. However, finding the developer responsible for one specific API in a live application can be difficult. That’s one reason why it’s more costly to fix a software issue in production than during the coding or design phases, because you often don’t know who’s responsible for fixing any issue that’s discovered. 

But when you find vulnerabilities by scanning application source code, you know who owns the project where the code is found. This makes it easy to assign identified vulnerabilities to a developer to fix. Checkmarx automatically creates and assigns bug tickets for discovered vulnerabilities, automating the process of getting security issues into the hands of the developers who can fix them.

8. Make it easy for developers to fix vulnerabilities

Traditional API security solutions, like WAFs and API gateways, can identify potential exploit attempts in live traffic targeting an API, but they can’t tell you whether a targeted API is vulnerable to any particular exploit. Identifying vulnerabilities in live APIs requires scanning the application with a DAST tool – either as part of a penetration test or automated in the DevSecOps pipeline. But even with a DAST tool, developers still must debug the API to understand an identified vulnerability before they can fix it.

As part of our overall developer experience, Checkmarx makes it extremely easy for developers to fix any identified vulnerabilities, with capabilities such as:

• Feedback tool integration – Checkmarx can automatically log bug tickets (e.g., JIRA) for discovered vulnerabilities and assign them to developers. Even better, we’ll automatically close the ticket when the vulnerability has been fixed.
• IDE integration – Checkmarx integrates with all the most popular IDEs to bring security findings into developers’ existing workflow, making it easy for them to fix vulnerabilities without ever leaving their environment.
• Best-fix location – tells you the exact line of code to optimally fix a vulnerability. Because of how applications work, fixing a vulnerability at the best-fix location can potentially address multiple vulnerabilities at once.
• Guided remediation – Checkmarx provides instructions on how to remediate a detected vulnerability – both in the bug ticket as well as in the IDE, to help developers even with limited AppSec expertise to fix vulnerabilities.

Checkmarx API Security

Checkmarx takes a different approach to API security. We help organizations discover all their APIs in code – including shadow and zombie APIs – and address security issues earlier in the SDLC, where they are less disruptive, time consuming, and costly to fix. Checkmarx API Security is available on our award-winning Checkmarx One enterprise AppSec platform, enabling AppSec teams to tackle API security as one part of a broader and more holistic application security strategy.

Making matters worse, while many API Security solutions may tout that they are “shifting left,” there’s a fundamental gap in their testing methodology, creating an opportunity for threat actors to capitalize on your zombie and shadow APIs. 

Many solutions today can’t identify zombie and shadow APIs, since they’re only scanning live traffic. 

Considering the rise of API Security attacks, it’s more important now than ever before to test during the API development process, as well as before they are pushed to production.  

What are zombie and shadow APIs

No matter how sophisticated a development team may be, undocumented APIs are likely hiding in your organization. Documented APIs are those APIs that development teams have provided the AppSec team with API documentation files, like RAML files, Swagger files, or OpenAPI files. These files describe what an API is, what it looks like, where it lives, and what parameters it has. 

Existing API security solutions like DAST, WAFs, and API gateways can only protect what they know. They must be configured per API to protect that API. What that means is that if the AppSec team doesn’t have the API documentation, or, if that documentation is incorrect, AppSec can’t configure the WAFs or gateways to protect those APIs. 

Shadow APIs are created under the radar—typically for a small use case, or they are created and deployed outside of an organization’s official API governance, visibility, and security controls. Shadow APIs may not have the proper authentication and access gates in place, or they may expose sensitive data improperly. Most importantly, with that lack of documentation, existing API security solutions can’t protect them.  

Zombie APIs arise in a slightly different way. For example, an organization could have a frontline API that was in production for some time, like an old version of a login API. When it’s time to update the application and login service, you have a new version of the same API. When developers create an updated API, they often don’t decommission the old version right away. Instead, the new API runs alongside the older API to ensure that the user experience isn’t impacted if any issues arise.

Eventually, you might forget about version one, since traffic is no longer going to the old login page, and your development team’s focus is now on version two. The problem is that the API is still lurking behind the scenes, leaving you potentially vulnerable to an attack. Since shadow and zombie APIs aren’t properly documented, a WAF doesn’t know about it, and can’t protect it accordingly. 

The problem with API discovery solutions today

There are new types of API threat protection solutions that have entered the market in recent years. Many API discovery solutions or threat protection solutions integrate with your WAFs, gateways, load balancers, and other network devices to analyze the traffic logs. By analyzing the traffic, they find all the API endpoints that that traffic is going to – they discover the APIs by looking at your live traffic going through these devices. 

It certainly helps, but it doesn’t solve the problem. 

The furthest left these solutions go is API documentation, but that doesn’t protect against undocumented APIs, or even worse, the APIs that are documented incorrectly. Many organizations don’t have a single choke point in application infrastructure that can integrate with, and see, all API traffic. 

So, while other solutions may say that they “shift left” in the SDLC, it’s often not the case.  WAFs say they shift left, but in reality, they only sit in front of production APIs. API threat protection solutions say they shift left, but they’re analyzing traffic to those live production APIs, on the far-right side of the SDLC. Instead, a shift left and integrate right approach is needed… 

Shift left, and integrate right, to protect your APIs

Instead of relying on API traffic, Checkmarx believes a shift left and integrate right approach for API Security is best, securing APIs as they’re being developed, as they’re being pushed into production, and helping you identify and protect against shadow and zombie APIs. 

Starting with the source code

Checkmarx API Security focuses on starting with the source code, understanding that there are likely gaps in API documentation. Checkmarx SAST identifies vulnerabilities, while Checkmarx API Security discovers the APIs in code, and builds a Global API inventory, along with API documentation risk by automatically scanning source code at check-in or code merge. 

For API-first organizations, that means you can easily validate API documentation in design, then compare against implementation to identify discrepancies. Checkmarx API Security of course scans API documentation (i.e., Swagger, RAML) files before your developers start coding to ensure that security is added into the design phase. This helps enforce API design best practices and assesses your overall API design for misconfigurations, identifying risks in path definitions, authentication schema, and transport encryption. For code-first organizations, it means you can discover and inventory every API in source code without requiring proper documentation, first. 

Change log to better leverage existing APIs

APIs allow developers to create modular software components that can be reused across different projects. Instead of rewriting the same code multiple times, developers can use an API to achieve the desired functionality. The problem we often see, is that without the full history or context behind a given API, developers may fear leveraging the API and modifying it for their needs. As a result, developers will often create a new API from scratch. 

The change log provides a full history of every change made to a given API, giving developers the full confidence they need to leverage existing APIs. Beyond developers having the full history at their fingertips, AppSec managers can also leverage the change log to quickly identify, for example, if a given public-facing API has a recent change adding sensitive data. As a result, developers and AppSec teams can better align with the true spirit of APIs; their agility, and ability to be repurposed, by finally having all the context they need to confidently leverage and repurpose existing APIs.   

A better developer experience

Checkmarx API Security integrates and automates scans in the tools developers use, enabling developers to remediate vulnerabilities in their favorite tools allowing them to kick off an application scan at any time using the CLI, and not wait until after code check-in to focus on security. It also provides guided remediation to help resolve vulnerabilities faster by prioritizing, recommending mitigation points, and surfacing just-in-time learning for discovered vulnerabilities. 

Single view to manage all API risk

Providing AppSec managers a full view of all APIs, Checkmarx aggregates and correlates the results from all the different scan engines for a more accurate picture of your application security. The Global API Inventory is where all of your APIs from all of the different projects are viewable in one place. This view helps AppSec teams focus on the most critical issues by prioritizing API vulnerabilities based on their real impact and risk.  

What’s new in Checkmarx 3.0

Brand new this fall, we now have pre-production testing of all the APIs in DAST.  This new capability complements our original shift-left approach with one that now also integrates right.The integration of DAST and API Security provides a more comprehensive view of API security risks, enabling customers to identify and remediate risks earlier in the development lifecycle. It works by DAST executing the API to evaluate the security risk. With a complete and up-to-date inventory, you can figure out the risk of the API before it goes into production.

Also new in the Checkmarx One 3.0 launch, Checkmarx API Security now automatically scans API documentation files, saving you time and effort vs. scanning API documentation files manually. This works when a user defines a rule in the project or globally using regex on the destination of the swagger files, so that every API security scan will scan the same swaggers without having to upload them manually. For example, a user could write a regex that scans all swagger files according to the *swagger.json regex. When someone adds a new swagger that matches this regex and pushes the code, the engine will run API Security with the new swagger.

You can’t secure what you can’t see

Checkmarx API Security provides complete API visibility, providing the most accurate and up-to-date view of the entire API attack surface, eliminating the problem of shadow and zombie APIs.  

A true shift-left approach means we discover APIs at the source, to find every API that’s written in the code, to identify and fix problems earlier and faster in the SDLC. 

Prioritized remediation helps developers and AppSec teams focus on the most critical issues. 

The total result is a holistic view of application security risk, scanning the entire application with a single solution, and removing the need for additional API-specific tools. 

While scanning source code and identifying shadow and zombie APIs is a big leap for API Security, we’re just getting started. Stay tuned for an upcoming announcement to correlate source code with runtime to better prioritize risk and improve accuracy.  If you’d like to learn more about Checkmarx API Security, register for the upcoming webinar  “Shift Everywhere to Secure APIs” on October 30^th, where you’ll hear from Checkmarx API Security Product Manager Liad Levy. 

The fact that microservices are popular, however, doesn’t mean they are always the right architectural solution for a given application. Although microservices have a lot of benefits to offer, they can also create challenges in areas like observability, security, and beyond.

So, before jumping on the microservices bandwagon, it’s critical to understand the pros and cons of microservices architectures. This article does that by briefly defining microservices, then discussing the three biggest advantages and disadvantages of using a microservices-based design.

Microservices, Defined

Microservices are a type of software architecture that breaks application code and functionality down into discrete, loosely coupled units that communicate with each other over the network. This makes microservices different from so-called monolithic applications, in which all application components run as a single, tightly integrated program.

There are many ways to go about designing and implementing microservices. You don’t need to use a certain programming language or a special platform or infrastructure to create microservices apps. Nor is there a minimum number of services you have to create for your software to count as a microservices application. As long as you break the application into discrete, loosely coupled parts, it’s a microservices app, no matter where it’s deployed or exactly how you define each microservice.

3 Main Advantages of Microservices

If I had to explain why microservices have become so popular in recent years, I’d point to three key advantages that they offer: scalability, ease of deployment, and fault tolerance.

Scalability

Microservices help applications to scale in two main ways.

First, microservices make it feasible to scale individual parts of your application in response to fluctuations in demand. For example, if there is a spike in login requests to your app, you can create more instances of the microservice that handles authentication. Because you only need to scale up this particular part of the application, scaling is faster and more efficient than it would be if you had to create more instances of a full application.

Second, because each microservice in an application is typically small, spinning up additional instances (or spinning down unnecessary ones) is faster and easier than spinning up a complete application. There’s less code to deploy, and less compute time needed.

Simpler Deployment

Beyond facilitating scalability, the small size of microservices means that they are easier to deploy in general. Deploying a new version of a monolith requires moving a fairly large amount of code into production, then spinning up the application. Plus, you’d also have to build, stage, and test the entire monolith before you could deploy a new version, which also significantly slows down the process.

With microservices, deployment is faster and less complicated because you only have to deploy one microservice at a time. Typically, you can update one microservice in your app while continuing to use older versions of other microservices.

Fault Isolation

Because microservices break applications into discrete parts, the failure of one microservice doesn’t typically cause the entire application to crash. In this way, microservices create fault tolerance.

On balance, it’s important to recognize that fault tolerance alone doesn’t guarantee application reliability. If a critical microservice fails, the application may effectively stop functioning, even if the other microservices keep running. For instance, if your authentication service goes down, users won’t be able to log in, so the app will still experience a critical disruption.

Still, microservices provide some ability for applications to continue working even when part of the application fails. Users who are already logged in, for example, would most likely be able to continue using the app even if the authentication service failed. That beats having a monolith where everything fails completely due to a failure in any one part of the app.

The Top 3 Disadvantages of Microservices

On the other hand, microservices can pose challenges. The biggest are management complexity, observability challenges, and heightened security risks.

Management Complexity

Managing any type of application is challenging, but managing microservices apps is especially challenging.

The reason why is simple enough: microservices mean that there are more moving pieces within your application. By extension, there is more to configure and more to deploy. (Indeed, although deploying each microservice is simpler than deploying a monolith, the fact that you have to deploy each microservice separately means you end up having many more deployment processes to plan and manage.) There is also more room for things to go wrong due to misconfigurations, malformed requests between microservices, infrastructure failures, and so on.

Observability

Observing microservices applications – which means collecting and analyzing data from them in order to understand their state – is harder than it is with monoliths, for two main reasons.

The first, and simplest, factor is that there is more data to collect, and more sources to collect it from, because you are dealing with multiple microservices. With a monolith, you’d typically have only a handful of data sources (like an application log and a server log) to deal with.

Second, to observe microservices effectively, it’s critical to be able to correlate and compare observability data from your various microservices. Thus, you face the challenge not just of collecting more data from more sources, but also of figuring out how to put all of that data together in a way that provides meaningful context. Modern observability tools can simplify this process to an extent by automatically interrelating data from discrete microservices, but you’ll still need to configure observability rules manually in some cases to gain as much insight as possible into your application.

Security Challenges

There is nothing inherently insecure about microservices. In fact, in some respects, you could argue that microservices are more secure in the sense that the breach of one microservice doesn’t necessarily mean your entire app is breached.

On the other hand, the fact that microservices are more complex, and that they introduce more moving parts to an application, means that securing them is harder. You have more configurations to worry about, which means there is a greater risk of misconfigurations that could create security vulnerabilities. At the same time, it can be harder to detect anomalies within the complex patterns of communication between microservices. That means attacks are not always as visible.

On top of this, microservices typically require the use of additional layers of infrastructure, such as an orchestrator and a service mesh. By extension, microservices create a larger attack surface, which also heightens security risks.

All of these security challenges can be addressed, but they require more effort than you’d typically need to secure a monolith.

Conclusion

To decide whether microservices are right for you, weigh what’s most important in an app. Are benefits like scalability, ease of deployment, and fault isolation worth more than the challenges of managing, observing, and securing microservices?

There’ no universally right or wrong answer to that question. But there is a right or wrong answer depending on your circumstances. Deciding when – and when not – to use microservices hinges on answering that question for yourself.

Chris Tozzi has worked as a Linux systems administrator and freelance writer with more than ten years of experience covering the tech industry, especially open source, DevOps, cloud native and security. He also teaches courses on the history and culture of technology at a major university in upstate New York.

.

.

Anyone who develops applications built on microservices architectures understands that APIs are a foundational element that must be secured. To learn more about our how Checkmarx can help you secure your APIs, click here.

Last week, one of the largest telcos in the Asia Pacific regions was compromised. The attackers scraped customer data, including personally identifiable information (PII), via an unsecured API endpoint publicly available on the internet. The attackers released sample data of a few users, including names, email addresses, physical addresses, passport numbers, driver’s license numbers, birth dates, whether a person owns their home or not, and more. The leaked data includes both current and former customers.

Not only was the data stolen but also it was used. There were reports that driver’s licenses, passports, and national IDs were applied for on the victims’ behalf, constituting a serious risk of identity theft. A few users reported they received a direct email asking for a $2,000 ransom to delete their data.¹

The intruders were able to fetch the data using an API that is believed to have had no authentication in place and provided direct access to the attackers for stealing the data. After leaking the data of 10,200 users, the attackers ostensibly had a change of heart and issued a public apology stating they deleted the data, however, we can only take their word as there’s no evidence to suggest they did not successfully sell the leaked data.

After a week (28-Sep-2022), the Medical Record ID for thousands were reported to be compromised via the same exposed API endpoint.² Though this has already ignited the fire for lawmakers to impose stricter norms, proactive actions are necessary.

How can “shift-left” for API testing help?

Shift-left is an approach to software and system testing in which testing is performed earlier in the development life cycle. Developers are empowered to scan their source code and remediate identified vulnerabilities rather than relying on a separate team or process.

Traditional API protections are run-time focused, where API Gateways or Web Application Firewalls (WAFs) can only secure the API endpoints of which they are aware. In the case of the telco data breach, it appears that they were either unaware that the API endpoint existed or that it was exposed publicly, meaning an API Gateway or WAF may not have stopped the breach.

By analysing the underlying source code of the application’s APIs using static application security testing (SAST), vulnerabilities can be identified and thus remediated earlier, saving organizations time, effort, and monetary resources. And by scanning APIs at the source, organizations can identify otherwise undocumented endpoints (known as shadow APIs), such as what appears to be the case that led to the data breach of the APAC telco. Of course, you need a good platform to do the analysis.

How can Checkmarx API Security help?

The Checkmarx One Application Security Platform includes our API Security scan engine, which uses static code analysis to identify and inventory API endpoints, the request and response data associated with those endpoints, and any related vulnerabilities. By scanning applications and APIs at the source, we identify vulnerabilities earlier and provide pointed guidance to developers and AppSec teams on where best to address the vulnerabilities before releasing code to production.

Checkmarx API Security scans source code, indexing the data flow through the code and capturing potential vulnerabilities using a set of queries.  We index, enumerate, and correlate our scan findings, providing developers and AppSec teams the specific file path and line number where the vulnerability was found. Furthermore, we provide pointed remediation guidance—as necessary—on the identified vulnerability.  In the image below, we see a SQL Injection vulnerability associated with a specific API endpoint.

Because we have visibility of the underlying source code for the API endpoint, we can capture and provide details of the APIs associated parameters and whether it exposes any sensitive data, such as usernames or passwords.

What are the benefits of using source code API security?

• Complete API visibility: Provides AppSec teams with the most accurate and up-to-date view of their entire API attack surface, eliminating the problem of shadow and zombie APIs.
• True shift-left approach: Discovers APIs in application source code to identify and fix problems earlier in the SDLC–faster with lower cost and risk.
• DevOps readiness: It can be easily integrated with DevOps platforms.
• Prioritization remediation: Focuses developers and AppSec teams on solving the most critical issues by prioritizing API vulnerabilities based on their real impact and risk.
• Holistic view into application risk: Scans the entire application with a single solution (SAST and API testing), eliminating the need for additional API-specific tools to reduce the overhead on over-burdened AppSec teams.
• Prevent vs. protect methodology: Source code analysis for API Security allows teams to create more secure APIs early in the SDLC and give fast feedback to developers, preventing issues from being pushed into the product.
• Knowing which application/project the API belongs to: reduces the time it takes to fix the problem.

Conclusion

This recent unfortunate example underscores the importance of analysing APIs at the source. By leveraging Checkmarx API Security, available within the Checkmarx One Platform, organizations can proactively protect against attacks such as these, helping to protect their customer data and reputation.

Reach out to a sales team today for more information or a live demonstration!

¹ https://www.crikey.com.au/2022/09/26/optus-hack-cyberattack-reform/
² https://www.youtube.com/watch?v=x9YIb46kPS0

c{api}tal (Checkmarx API Training and Learning) is a purpose-built vulnerable API application based on the OWASP API Top 10 risks. It is built with Python (FastAPI – a quick and easy to use web framework for developing RESTful APIs in Python) and JS (React), and it includes 10 API security challenges.

c{api}tal was created by the Checkmarx Research team to provide users with a “playground” so they could learn and develop their API Security skills. It can be used to learn and exploit API Security vulnerabilities and for conducting your own API Security Capture The Flag (CTF) event.

In computer security, Capture the Flag (CTF) is an exercise in which “flags” are secretly hidden in purposefully vulnerable programs or websites. The goal is to complete challenges as fast as possible, get the highest score, and win the competition. Visit capital-ctf.com to learn about the vulnerabilities and the challenges.

We first introduced C{api}tal to the application security (AppSec) community at 2022 AppSec Village at DefCon30. It was an amazing experience! Dozens of users participated in the event, while only 6 of them were able to complete the 10 API challenges.

We think of all participants as winners for being able to up-level their security skills (why we were all at DefCon), but we obviously must pick 3 for the contest. Full credit goes to the winners:

Once the event ended, many awesome write-ups were done by security analysts and researchers who took part in the CTF event. One great example is this medium write-up by Maor Tal.

Digging into API risks

c{api}tal is a vulnerable, blogging application that allows users to register, create and delete posts, create and delete comments, follow other users, and more. The application can be built and deployed by running a simple docker-compose command:

docker-compose up –d 

Some of the API endpoints in c{api}tal can be seen here:

The application contains 10 risks that align to the OWASP API Top 10 Risks:

• Broken Function Level Authorization
• Broken Object Level Authorization
• Broken User Authentication
• Improper API Management
• Excessive Data Exposure
• Improper Assets Management
• Lack of Resources and Rate Limiting
• Security Misconfigurations
• Injection
• Mass Assignment
• Security Misconfiguration
• Insufficient Logging

In this blog, we will cover Broken Object Level Authorization (AKA BOLA) and Mass Assignment challenge.

Broken Object Level Authorization

Object level authorization is an access control mechanism that is usually implemented at the code level to validate that only one user can access objects that they should have access to.

Every API endpoint that receives an ID of an object, and performs any type of action on the object, should implement object-level authorization checks. The checks should validate that the logged-in user does have access to perform the requested action on the requested object. Failures in this mechanism typically lead to unauthorized information disclosure, modification, or destruction of all data. In simple words, BOLA allows a user to have access to fetch/update/delete any resource that they should not have access to.

How to exploit BOLA in a vulnerable application? Let’s look at this example.

This application contains an article written by “Blastoise”, which announces that “Whoever comments first will get 1,000,000$ from Pikachu”. Going into the article, we can see it received two comments as shown below:

As you can see, “Bob_the_dev” was second to comment in this article, and he wished he was the first to comment. Let’s demonstrate how we can take advantage of a BOLA vulnerability to make Bob_the_dev number 1.

We would like to try to delete the first comment of “Blastoise”, an action which we should not be able to perform if BOLA mitigation is in place.

PoC demonstrating a BOLA exploit:

We successfully deleted “Blastoise’s” comment while being authenticated to another user, which means the application is vulnerable to BOLA and we got the flag!

How is Bola allowed in the application?

delete comment route

and

delete_comment_from_article 

function is defined.

We can see the code does not contain a check for the user who requests to delete the comment, and therefore, any (authenticated) user is able to delete any comment, even if it is not their own.

Mitigation

The way to mitigate this type of risk is to have a proper check of the user who tries to access/update/delete any resource in the application. In case they are not the user who should have access to this resource, the application should block the request.

if comment.author != current_user:
 raise HTTPException(
 status_code = status.HTTP_403_FORBIDDEN,
 details = “Forbidden”
)

Mass Assignment

An API endpoint is vulnerable if it automatically converts client parameters into internal object properties, without considering the sensitivity and the exposure level of these properties. This could allow an attacker to update object properties that they should not have access to.

How to exploit Mass Assignment in a vulnerable application?

When a user tries to register/login to the application, the response the application returns with contains one interesting field that should not be there—“admin” parameter.

A default user in the application is not an admin, so why don’t we try to change that?

PoC demonstrating Mass Assignment exploit:

How is Mass Assignment allowed in the application?

Here is a snippet of the application code where the user profile returns the “status” of the user in terms of admin permissions as a new parameter in the response – “admin”. We can see the code does not restrict users from modifying such parameters, so any user could update his profile and modify his admin permissions:

We were able to modify the user’s permissions and now the user is an admin! And in the context of the CTF event, of course, we got the flag as well.

Mitigation

The way to mitigate such risk is not to expose sensitive properties and not allow users to update object properties that they should not have access to.

Final Thoughts

APIs are a critical part of modern mobile, SaaS (Software as a Service), and web applications and can be found in customer-facing, partner-facing, and internal applications. By nature, APIs expose application logic and sensitive data, potentially leading to data breaches, account takeovers, and much more. Because of this, APIs have increasingly become a target for attackers.

Without secure APIs, organizations would face many security risks and rapid innovation would be impossible. Therefore, it is extremely important to be aware of the OWASP API Top 10 risks and enforce proper API security mitigations for your APIs.

To help developers and AppSec teams improve their API security skills, Checkmarx researchers developed c{api}tal, which again, is a built-to-be-vulnerable API application based on the OWASP top 10 API risks.

Feel free to use c{api}tal to learn, train and exploit API Security vulnerabilities within your own API Security CTF event. c{api}tal will soon be available as an open-source project on GitHub! We encourage you all to be proactive and sharpen your API security and overall code security skills!

To learn more about Checkmarx approach to API security, and overall application security testing, request a demo of our Checkmarx One Application Security Platform today. Or sign up for a 14-day free trial here.

Understanding inventory and what should or should not be part of the corporate ecosystem, control over those endpoints, incident response, policy, compliance, malware … The list of challenges is at best constant, at worst, ever-growing. It’s not a new problem but one that remains difficult to solve. It seems that infrastructure and security teams are relegated to robust reactive measures (e.g., incident response) when proactive measures are undermined by careless or thoughtless users.  

There is a certain level of irony in the fact that APIs (application programming interfaces) are often referred to as endpoints as well. Architecturally, APIs are designed to make software more extensible and offer flexibility to unique and custom use cases. Each API is defined as a contract, which accepts certain input and provides certain output. Most modern software leverages private APIs to proffer out-of-the-box functionality as well as public APIs, which users of the software may interact with to extend functionality or cater to their own specific use case. 

Much like physical (or virtual) machines on a network, APIs represent a significant viable attack surface area for would-be attackers. What’s more, command and control over APIs, how they’re built, what security mechanisms they employ, the data they expose, and how and when they are released or sunset is an increasingly challenging problem that organizations are forced to deal with.  

Security teams often aren’t advanced enough to look into what developers are deploying; documentation of APIs is often lacking; version control is often missing; and as a result, the underbelly of deployed applications is (unintentionally) exposed. Some security reports suggest that 40 to 50 percent of organizations have experienced an API breach in the last year, and research also suggests that an overwhelming volume of API traffic is malicious. Well-known companies like Peloton, LinkedIn, Experian, and John Deere have all dealt with the fallout of API security challenges. 

For the developer audience that may be interested in common weaknesses of APIs and how they’re built insecurely, consider reviewing the OWASP API Security Project. For the security architects and risk managers, there are a couple of obvious first steps to gain ground on the API challenge. 

First, you cannot protect, regulate, or inspect what you don’t know about. Discovery, much like infrastructure endpoint security, is a very critical first step. Second, once you know what’s out there, you need to gain an understanding of what type of data may be exposed by these APIs. APIs that expose sensitive data should be known, documented, and properly secured. Lastly, find out what exploitable weaknesses or vulnerabilities may be lurking in the implementation of that API (see OWASP API Security Project). 

Seems easy, right? 

Most security tooling for API security lives in runtime space. This means these tools can examine, in real-time, API calls and the data that these APIs are delivering. But in many cases, this is too late. These tools support a reactionary model that relies on stopping malicious actors just in time, if at all, and they are less capable of detecting data sensitivity concerns or vulnerabilities in the implementation of an API. 

A better way to do API security is to shift left and look at the code developers are writing. With this approach, discovery, data sensitivity issues, and exploitable vulnerabilities in API code can be identified simply by interrogating code stored in a repository. All this can be done well before any APIs are deployed in a production environment. The opportunity to trap security issues well before they are a legitimate risk, and when they’re cheaper to fix, is significant and a game-changer in the API-security space. 

API security tooling isn’t new, but it’s never been done the Checkmarx way. To learn more, check out Checkmarx API Security. 

Because the problem is organizational, the solution to the problem can’t be a reactive one. It must be proactive. With API Security, Checkmarx is taking a fundamentally different approach, a true shift-left approach to help proactively address the problem of shadow and zombie APIs.

What is an API?

API stands for Application Programming Interface. It’s a set of definitions and protocols (e.g., REST, SOAP) that define how you can communicate with a software component or service. This may sound abstract, but it’s really not. It’s basically just a mechanism to perform a transaction – you request information by asking the right question, and the application provides it in response.

Think of the real-world analogy of a bank transaction. I can go into a bank and request money by filling out a withdrawal slip and handing it to the teller, along with my ID to prove that I’m the account owner. Here, I’m the client. The teller is the API. My name, account number, and ID are the parameters that I pass to the API. The money being withdrawn is the data. And the deposit slip is the API documentation.

Why are APIs important?

APIs are a key architectural component that enables broader architectural changes like cloud migration, shift to microservices-based architectures, and agile development. APIs allow for an application to be broken down into multiple smaller components (e.g., microservices), by establishing a clearly defined protocol for those different components and services to communicate and share data with each other.

Figure 1: an example ecommerce web application comprised of microservices deployed across multiple cloud providers and SaaS services.

For example, organizations building a cloud-native application typically split the application into many smaller microservices that must communicate with each other to comprise the whole. This allows them to scale different microservices with different scaling requirements independently of each other to better take advantage of the cloud. In addition, different developer teams can build, deploy, and update different microservices independently of and in parallel with each other, allowing them to move and release software faster.

What is API security?

When you visit a website in your browser, that browser may be showing content and data retrieved from different backend application services using APIs. Likewise, when you open a mobile app on your phone, that mobile app also typically retrieves data from backend services using APIs. These browsers and apps are communicating with APIs over the open Internet, which means… that those APIs must be publicly available on the Internet.

When you combine that with the fact that the primary purpose of APIs is to share data – and share data more efficiently – APIs are ripe for abuse. What type of abuse? The OWASP Foundation maintains a list of the API Security Top 10 risks to help security professionals understand the different types when building APIs. Erez Yalon does an excellent job breaking these down here. Regardless, with the prevalence of publicly exposed APIs, it is no wonder that the number of API-based attacks are increasing. In this recent example, Checkmarx researchers discovered a vulnerability in the Amazon Photos Android app that would have allowed an attacker to steal a user’s Amazon access token and use it to authenticate with and access other API-based Amazon services to steal PII (Personally Identifiable Information) or other information.

API security refers to the task of securing APIs from attack, either by identifying and blocking live attacks, or fixing vulnerabilities in APIs before they go live and can be attacked.

Why is this a problem now?

API security has always been a problem. However, recent years have seen rapid growth in the use of APIs when building modern applications. For example, Postman reported a 56% growth YoY in the number of API requests in its 2021 State of the API Report. And 49% of developers surveyed said that more than half of their organization’s development effort was dedicated to APIs – an increase of over 40% from the previous year.

This growth has dramatically increased both the attractiveness of APIs as a target of attack, as well as the severity of the challenge facing application security teams. The size of the problem keeps getting bigger every year. Security teams are realizing that they cannot kick the can down the road forever, or continue reactively plugging holes, and need a permanent solution now.

OK. So why hasn’t this problem already been solved?

First, a disclaimer – there are existing API security solutions today. In the AST (Application Security Testing) market, vendors including Checkmarx have always helped secure applications against OWASP API Top 10 risks, simply by scanning API code for vulnerabilities. And runtime solutions like web application firewalls (WAFs) and API gateways have provided varying levels of API protection capabilities for years. However, these solutions have not solved the problem, because the problem is not really that we cannot protect an API against attack. The problem is that security teams do not know what APIs they have.

Figure 2: existing API security approaches are limited by what they can see.

Consider a WAF (Web Application Firewall). Security teams can configure a WAF to protect an API. This requires registering the API with the WAF appliance, so it knows where the API is (the URL), what it looks like (parameters), and what good traffic looks like (a positive security model). Because an organization can have 100’s or 1000’s of APIs that frequently change, manually registering every API is not practical. The better way is to import API documentation or design files that describe the API in a standard format, such as Swagger, RAML, or Open API. However, there are two problems here:

1. The first is that many APIs are not documented. Sometimes, developers do not document an API. Other times, nobody shared that documentation with security. Regardless, if security teams do not have the documentation, then they do not know about the API, and they cannot configure the WAF to protect it.
2. The second problem is that Swagger and RAML files are typically created in the design phase before coding begins. APIs then must be coded, and developers may inadvertently stray from the design when coding the API. Bugs happen. Many API vulnerabilities result from differences between an API’s documentation and what was actually written in code, and these cannot be found by looking at the documentation.

More recently, API threat protection solutions have entered the market to discover undocumented APIs. These work by integrating with WAFs, API gateways, and other network devices such as load balancers. They analyze the traffic going through them to discover some of your shadow APIs that the traffic is going to, but cannot solve the problem, because:

1. They are limited to what they can see. They can only see the traffic going through the devices they integrate with. If there are APIs that are not behind these devices, then they cannot see them. Think about your application infrastructure. How many services do you have, and where are they deployed? How many WAFs, API gateways, and load balancers are in your environment that would need to be integrated with? And how often does your infrastructure change, affecting where services are deployed and where traffic flows?
2. The other problem is that you are still trying to fix the problem in production. While these solutions may claim to be “shift left,” analyzing live traffic to APIs already in production is not. First, APIs may already be under attack. But more importantly, discovering APIs in production means that security teams must go back and find the developers who coded them. And by the time they do, those developers have already moved on to other projects and have to context-switch back, lowering their productivity and slowing down those other projects.

Figure 3: Checkmarx takes a fundamentally approach to discovering and inventorying APIs

Great, how do you do it differently?

Checkmarx API Security takes a true shift-left approach to help customers address the problem of shadow and zombie APIs. This is a fundamentally different approach to the problem than other solutions described above, which follows several key tenets:

Figure 4: Four key pillars to the Checkmarx solution

• Discover and inventory APIs in source code:

All the solutions described above are dependent on security teams knowing all the chokepoints in the application infrastructure through which API traffic flows. The problem is that most security teams do not know all the chokepoints for all their applications, and the chokepoints they do know continuously change as application services are deployed, moved, or changed.

Instead, Checkmarx scans application source code as it is checked in to discover and inventory all the APIs that are written and exist in code. This happens while scanning source code for vulnerabilities, which we then connect to the specific APIs in which those vulnerabilities are found to provide an API-centric view on risk. Imagine being able to look at all your APIs, pick your most critical ones (for example, your login APIs), and prioritize vulnerabilities in those APIs based on severity.

• Compare source code with documentation:

Many API vulnerabilities happen when an API is coded in a different way than what was documented. That means you cannot identify a risk or vulnerability solely from looking at the documentation. You also cannot configure security controls without validating the documentation.

Rather than rely solely on API documentation, Checkmarx API Security does two things:

1. First, it identifies APIs that exist in source code but do not exist in documentation. Providing this inventory of undocumented APIs gives you a complete view into your shadow and zombie APIs, regardless of where they are or whether they are behind a WAF.
2. Then, we look at the documented APIs and compare how the API is written in code against its documentation to identify data discrepancies that can lead to a vulnerability.
3. Make it easier for developers to fix problems before APIs go into production

Checkmarx API Security integrates with Checkmarx SAST to scan source code as it’s checked in. When vulnerabilities are found, Checkmarx automatically creates bug tickets (such as with JIRA) for that vulnerability. This puts the vulnerability in a context that developers understand and are used to fixing as part of their day-to-day routine – the software bug.

Security teams can identify shadow APIs and track vulnerabilities discovered as the API code is first checked in. This allows security to work with closer developers earlier in the SDLC, to properly document APIs and address any vulnerabilities found.

So, what’s the bottom line?

Taking a true shift-left approach can give security teams complete visibility into their API footprint. By integrating with the SDLC during the design, coding, and check-in phases, Checkmarx API Security offers an easier way to keep up with the continuous change in the API environment – and enable your developers to fix any problems found.

Figure 5: taking a true shift-left approach to API security allows you to discover all your APIs

But perhaps the final advantage is that, with Checkmarx, this can be done without the need for any additional tooling. You don’t need to purchase, deploy, and manage an API-specific solution that doesn’t solve the entire problem. Instead, you can find your shadow and zombie APIs with the same AST solution you already have and are already using to find and fix vulnerabilities.

To find out more, go to https://checkmarx.com/product/api-security

This may sound cliché, but the harsh truth is that many public APIs contain numerous vulnerabilities. Therefore, properly securing APIs so that the worst-case scenario doesn’t become a reality is a major challenge for development teams.

This article aims to give the reader a better understanding of what will work and what won’t work in the context of API security. We will walk you through the most essential considerations, taking into account the fact that there is no silver bullet for API security due to the ways in which APIs are built and deployed.

Let’s get started.

Reasons Why APIs Are Hard to Test and Secure

APIs come in all shapes and sizes. The most critical parts of an API are often the most susceptible to attacks on vulnerabilities like those listed in the OWASP API Security Top 10. For example, attackers might attempt to abuse paths for logged in users, exfiltrate sensitive data by fuzzy testing the endpoints, or force the site down using DDoS attacks. As the API surface increases, of course, so does the risk of exposure. Imagine having to protect APIs with hundreds of endpoints, each with its own conventions.

This could happen quite easily when there are multiple teams working on the same project and contributing to the same API. The API might not have a sole owner; instead, it might be exchanged between multiple stakeholders (such as project owners, developers, testers, operations, and network and security teams), with each group submitting their own piece to deliver new features to their customers.

Relying too heavily on some parts of the delivery pipeline to include sufficient security controls is equally problematic. For example, you shouldn’t rely on the development team to constantly provide the most secure software all the time. Developers do not habitually think like attackers. They will incorporate basic pragmatic reasoning and accept logical trade-offs when delivering sprint goals. However, they will miss important security considerations fairly often simply because they are generally unaware of use and abuse scenarios. Likewise, if you expect your WAFs to perpetually block all unwanted traffic and your static code analyzers to always pinpoint all security flaws in the code, then you will be in for a big surprise when attackers exploit unknown vulnerabilities or zero-day bugs.

Therefore, since APIs are hard to test and secure, you must be innovative in finding conventional tools, agile methodologies, and various approaches that work well together. Let’s explore some of them.

Tools and Approaches That Work Well Together – and Some That Don’t

Once you have established that you need to use flexible approaches to keep your APIs secure, you want to make sure that you are following the right guidance. There are lots of great guides and best practices for API security, but it’s important to differentiate the ones that make the most sense for your APIs from the ones that don’t.

Some of the approaches that work with API security are mainly focused on establishing in-depth defenses:

• Authenticate and authorize by default: When you are developing APIs, you should explicitly mark unauthenticated endpoints (and not the other way around). For example, you should protect all endpoints with strong authentication (2-factor) and assign a default role that cannot read or modify any data. That way, there is less risk of exposing new endpoints that do not have any sort of protections.
• Use API security scanners: Tools and services in this category include runtime protection, DAST (vulnerability scanning tools), static code analyzers, and security bots. These tools provide a nice layer of defense against baseline security issues.
• Use penetration testing: You can hire professionals who think like attackers and are able to perform sophisticated tampering. These professionals have access to unconventional tools and leverage techniques that help expose issues that security scanners won’t pick up by default.

On the other hand, some approaches might not work in the long run because they possess inherent risks. For example:

• Security through obscurity: This means that we try to secure part of the API by making it harder to use or to discover its endpoints or behavior. This is like an Easter egg hunt where you expose certain parts of the API only to clients that know where to look for them. Or you might make it harder for attackers to guess some of the API schemes by using special query parameters or headers. Although this approach might work for certain cases, it is not considered 100% secure. Cunning attackers might figure out a way to uncover those hidden parts of the API or infer how the API response works, which would give them the ability to retrieve sensitive information.
• Using JSON Web Tokens (JWTs) for storing sensitive data: JWTs offer a good balance between security and convenience when working with APIs – as long as you abide by the rules. If you store sensitive data in the JWT payload, for example, you are already compromising security since JWTs can be decoded easily. Always use industry-standard JWT libraries, strong JWT secrets, and short expiration tokens. In addition, always use HTTPS.

We mentioned before that APIs can be secured by automating the scanning of application code. Let’s explore that in more detail.

How to Effectively Scan APIs

Start with the source of truth, the source code. By scanning the source code, you get a complete view of what APIs are inside of a project. This also allows developers to easily and quickly fix any security issue that has been identified by this static analysis. Since APIs need to be human-readable, scanning the API Documentation as Swagger can also be key to identifying risk—checking key risks like access control, configurations, and best practices. This is an example of shift-left security, wherein DevOps teams ensure that security is built into application development rather than added on later.

Next, once those APIs are moved to an environment, it is easy to perform real E2E tests based on predefined rules against your real API. If the scanner finds any defects or suspicious red flags, it will report them to a dashboard for triaging. These scanners include many checks (like the OWASP API Security Top 10 and open CVEs) and can automatically create policies without intervention.

Even if you have a perfectly valid specification file, though, it doesn’t mean that the scanners will find all of the issues. It’s equally important that you are able to feed the scanner raw HTTP recorded sessions using either Fiddler or Burp so that it can verify unknown parts of the API.

Ways to Address the Continuous Development of APIs and Ever-Changing Contracts

At the end of the day, how can you address the continuous development of APIs and ever-changing contracts when you have to contend with multiple attack vectors in real time?

There are several options to consider:

• Scan early and often: Software is developed at the speed of light nowadays.The only way to keep up with the ever-changing contracts is scanning the API Documents and Source Code when they are changed by the development team.This can alert them immediately to critical vulnerabilities and risk. Allow the developer to learn better practices and secure the APIs well before they are live.

• Create clean environments for security testing: Sometimes you can’t slow down the release of new features in the name of security. It’s important that security teams create special environments where they can introduce novel security testing tools and scanners for advanced security testing. The primary idea is to conduct intelligent analytics, pinpoint hidden attack vectors, and expose vulnerabilities without affecting the production environment. Once a security issue has been found and mitigated in this special environment, the security team can patch the production systems using the current change request system.

• Adopt DevSecOps workflows: DevSecOps is about integrating your IT security team into the full lifecycle of your app. Put simply, this means that security teams follow short and frequent development cycles, integrate security tools and vulnerability scanners with minimal intervention, ensure that all operational technologies run with the optimal security configurations, and promote a security-first mindset across isolated teams. This can be accomplished by including automated security checks throughout the CI/CD process and creating service templates that are secure by default for the development teams to adopt.

Next Steps with API Security

We want to conclude this article by emphasizing the fact that there is no way your APIs can be 100% secure at all times. Instead, organizations should be constantly vigilant to scan their APIs for risks and vulnerabilities. As a security professional, it’s crucial that you stay informed about the status of the API security ecosystem. Reading security advisories like the ones from Checkmarx is a great way to acquire this knowledge. Their advisories discuss real public exposures while providing deep root cause analysis and explaining mitigation tactics. Feel free to sign up for more tutorials about API security and DevSecOps.

About the Author

Theo Despoudis is a Senior Software Engineer, a consultant and an experienced mentor. He has a keen interest in Open Source software Architectures, Cloud Computing, best practices and functional programming. He occasionally blogs on several publishing platforms and enjoys creating projects from inspiration. Follow him on Twitter @nerdokto.

..

..

To learn more about the many risks (including APIs) in modern application development, download this e-book today.

Or if you would like to learn more about Checkmarx approach to API security within the Checkmarx One Application Security Platform, this white paper explains it all.