The State of the API: 2025 – Security, AI, and the Human Element

This blog post was generated by Gemini using the transcript from the podcast episode.

The API remains the "connective tissue of the modern world", but as Postman's Sam Chehab highlighted in a recent discussion with me, the State of the API report reveals that the landscape is rapidly evolving, driven by the rise of AI and persistent security challenges.

The Collaboration Crisis and the Security Connection

The annual Postman State of the API report, now in its seventh year , synthesizes data on how APIs are produced and consumed across industries. A major insight from this year's report focuses on the persistent struggle with collaboration. A shocking 93% of teams are struggling with API collaboration, which leads directly to a lot of duplicated work. From a security perspective, this fragmented collaboration means the "attack surface is getting wider". When developers find unofficial ways to share information—like Slack threads, wikis, or Confluence docs—it bypasses established security and governance processes.

However, there is a silver lining: documentation is on the rise. Fifty-eight percent of respondents cited documenting APIs as one of the most common activities they are undertaking to improve collaboration. While this is a step toward better practices, Sam Chehab notes it may be driven by the need for better collaboration or the demand for AI-ready APIs.

Shifting Left: Integrating Security into the Developer Workflow

Postman is primarily an engineering-first tool , used by 98% of the Fortune 500. The key to better security, according to Chehab, is working with the developer workflow, not against it.

The pathway to good security is a byproduct of good collaboration. This starts with the fundamentals: achieving an inventory of enterprise and software assets —the first two CIS controls—to kickstart the security journey. Postman enables developers to run security tests directly within their normal workflow using Postman collections. This drastically improves development velocity and moves security closer to the "shift left" ideal.

Furthermore, the platform's built-in load testing and performance capabilities help address the "Availability" component of the CIA triad, which security teams often historically ignore. Developers can trivially simulate denial-of-service attacks using their existing tests and Postman's features.

Preparing for the AI Agent Invasion

As AI agents increasingly consume APIs, they require a different approach to API design and documentation.

While developers often hate documentation, AI agents thrive on it. Tools can be leveraged to help write documentation about APIs that then other AIs can read. Humans may get away with a generic "error something broke" , but AI agents require rich, contextual error messages. These should specify the problem (e.g., "invalid parameter"), what was expected, and what was received so the AI can effectively process the issue.

AI also needs centralized information, clear metadata, and good descriptions around APIs to function effectively. This makes centralized platforms like Postman essential, replacing scattered wikis, portals, and Slack threads.

Top Security Concerns: Credentials and Amplification

One of the top security risks cited by 51% of developers in the report is unauthorized agent access.

This issue is primarily driven by the industry's failure to effectively solve secrets management , with API keys floating everywhere. Postman addresses this by providing tools for API key management, including forcing expiration, managing revocation policies, and having a "revoke all" option. Furthermore, Postman actively scans public repositories like GitHub for leaked Postman keys, auto-revoking them and notifying the administrator to minimize the blast radius of a leak.

Another risk is Credential Amplification. This refers to the risk that is exponential, not linear , where one credential grants access to one service, and that service then has access to another , allowing for lateral movement. This puts a name to what that sprawl looks like now.

The Emergence of Model Context Protocol (MCP)

A new concept discussed was the Model Context Protocol (MCP) , which is an emerging standard for AI interaction.

MCP acts as an abstraction layer. It sits on top of a restful-like protocol and allows you to abstract yourself away from the endpoint that you're communicating with. It enables the use of natural language to interact with a scoped-down number of APIs , making interaction with different services more agnostic (e.g., interacting with a Jira instance without hardwiring to it).

MCP, however, introduces a new supply chain risk. Security practitioners must validate which MCP servers they are using. Chehab cited the first benign "MCP hack" in the wild, where a malicious server added a BCC to an email every time an action was performed.

The Wrap Up

Chehab's final advice echoes his security philosophy: go back to basics. Secure your APIs by focusing on the fundamentals:

• Gain Leadership Buy-in: Security efforts will be fleeting without support from management.

• Document and Test: Focus on how you are documenting, sharing, and testing your APIs.

• Ensure Consistency: Validate that your design-time plan maps to what you build and what you deploy in runtime.

By solving collaboration and basic security problems first—and using AI to help automate those basic tasks —teams can successfully secure their systems before chasing new, complex AI threats.

Implementing Dynamic Application Security Testing (DAST) Tools into the SDLC

One of the questions that always came up at the end of my API talk was around Dynamic Application Security Testing (DAST) for APIs. I mention DAST in the talk but never really went more in-depth due to time constraints. The questions usually revolved around vendors. In this post I want to talk about how DAST works, I’ll mention vendors from my experience, and finally I’ll go over implementing DAST in the Software Development Lifecycle (SDLC).

HOW IT WORKS

DAST tests an application when it’s stood up and running, usually in a test environment. The test itself looks for the low hanging fruit because it’s running automated tests with no context or awareness of the business function of the application. It will run the same test against a finance system as well as an operational system. This tool is not a replacement for manual testing.

The tool will simulate what an attacker might do to an application. It will check for injection vulnerabilities and weaknesses within connections and protocols to the application. Again low hanging fruit so it will struggle with more involved techniques and misses simple things like URL enumeration and other abuse cases. Overall this tool is a great starting point for applications as it’ll capture a lot of the low hanging fruit but it won’t go much more in-depth than that.

Vendors

OWASP has a list of Vulnerability Scanning Tools AKA DAST available. The main ones I usually recommend are Tenable, Rapid7, and Invicti because I have familiarity with them. I always recommend evaluating multiple vendors before deciding on one. If you’re needing a DAST because of compliance reasons, I’d suggest Tenable or Rapid7 depending on which vulnerability management suite you already own.

If you’re wanting something for more than just compliance look at Invicti because that’s their only focus. This allows them to focus solely on the DAST technology. A Tenable or Rapid7 is looking at providing other security solutions not just DAST. From a low-cost perspective OWASP ZAP or BurpSuite are two free options that can be run manually or setup to automatically run in a CI/CD pipeline. The cost here is a resources time for learning and setting up the open-source tool.

IMPLEMENTATION

DAST is the easiest application security tool to setup in an SDLC. You need a URL, some login credentials, and a timeframe to scan. I recommend scanning as close to production as possible. Scanning in production is never a good thing because it’s throwing a lot of malicious types of attacks at an application. This can cause issues such as taking down the application or putting a junk data into your production environment databases. Scans can be setup to not be as aggressive but then it ends up missing vulnerabilities.

Scanning in a User Acceptance Testing (UAT) allows scans to run at the most aggressive level and not impact production. That is as long as the database isn’t shared with production. The only catch here is finding a time to run the scan so it doesn’t impact user testing. Scans can be setup to run in the afterhours.

The frequency of scanning should be based on how often code is released to UAT. If development is on two-week sprint then it’s reasonable to setup scans to run every two weeks. Some industries only require scanning applications once a month and that’s fine as well because as the vulnerabilities are addressed the need for DAST becomes less important.

Boom! Done!

Not so fast my friend!

Now that we’re scanning we need someone to look at and tune the results. This person should ideally be someone with application security experience because they’ll need to understand how the application woks or willing to dive in and learn. DAST has false positives. Not as many as a Static Application Security Testing (SAST) tool but it will have some. If results are taken from a DAST tool and sent to developers without any sort of vetting it will either tick off the development team or not get addressed. Often times both scenarios are the response.

If an application security person or someone willing to learn isn’t available then setting up a meeting with the development team to share findings and ask questions will go over a lot better. Developers are good people and love talking about their code (baby) and they’ll want to make sure it’s protected from the bad guys on the outside. This meeting will need to be a regular one for any new applications loaded into the DAST. As the vulnerabilities get tuned or addressed the meeting can be less frequent. As trust is built the meeting can become an email unless there’s some misunderstanding or a more complicated vulnerability needs to be addressed.

Summary

DAST is easy to setup but it’s the last tool to be kicked off. As more security tooling get’s implemented and the program matures the importance of DAST becomes less. It’s still a great starting point for any application security program. Always evaluate multiple DAST vendors. If it makes sense to go with a DAST that is already part of a suite of other tools then go with that.

The strategy for implementing DAST is the same for web applications as it is for APIs. You won’t see as many results for APIs because their use is more restrictive than a website. The main concern with APIs is authentication and authorization issues. DAST will be able to call out weak protocols but it will not be able to identify if a person has the access they need. Remember to work with the development team on getting DAST setup because their help will be needed for addressing vulnerabilities.

If you’re looking for an API vendor focused on testing, I’d recommend 42Crunch.

Drop a comment below if there are any questions or other topics you’d like me to cover. If you’re interested in services I have sponsorship, consulting, and speaking engagements available. Reach out via the contact form.

This blog post first appear on Exploring Information Security.