API Attacks Are Getting Faster. Your Security Stack Isn't Ready.
The security landscape has fundamentally changed. What used to take attackers 15 hours to accomplish now happens in 15 minutes. And if your security team is still thinking in terms of traditional detection windows, you're already behind.
Fernando Medrano, Deputy CISO at Fastly, has spent over 20 years building security programs that actually work in production. His recent insights reveal why most API protection strategies are failing and what teams need to do differently.
The New Reality of API Attacks
Traditional security tools were built for a different era. They assume attackers work slowly, methodically testing one pattern at a time. That assumption is now dangerous.
"API attack patterns are becoming smarter through automated means," Medrano explains. "You used to see humans behind the keyboard testing different patterns. Now it's automated and sped up because of the scale at which you can deploy these attacks."
The difference isn't just speed. It's intelligence. Modern attacks don't just blast endpoints randomly. They analyze responses, adjust tactics in real-time, and optimize their approach based on what they discover. What previously required human analysis between each attempt now happens automatically.
This creates a compound problem. Faster attacks mean smaller detection windows. Smarter attacks mean traditional pattern matching fails more often.
Why Rate Limiting Won't Save You
Security teams often lean on rate limiting as their first defense. It feels logical: limit the number of requests per user or IP address, and you'll slow down attackers.
But attackers understand rate limits better than defenders do.
"You can relatively quickly reach the limits of a rate limit and understand what that rate limit is," Medrano notes. "At that point, you can slow it down, get out of the sandbox, and programmatically assign how many queries to send over time."
Rate limits also have structural weaknesses. They're typically assigned by IP address, account, or region. Attackers simply create more accounts, use more IP addresses, or distribute attacks across regions. The protection becomes theater rather than substance.
Even when rate limiting works as designed, it doesn't stop sophisticated attacks. It just forces them to be more patient. And patient attacks are often harder to detect than obvious ones.
The Partnership Problem
The biggest misconception about API security isn't technical. It's organizational.
Most security teams treat API protection like traditional network security. Deploy a tool, configure some rules, and monitor alerts. But applications aren't networks. They're living systems that change constantly.
"The real value comes when you start digging into the specifics of how the application works and tune it to the customer use patterns you expect to see," Medrano explains.
This requires deep partnership between security and engineering teams. Not just consultation during major releases, but ongoing collaboration as applications evolve. Security professionals need to understand application logic. Engineers need to think about threat patterns.
Most organizations struggle with this partnership. Security teams don't have application context. Engineering teams don't have security expertise. The result is generic protection that misses sophisticated attacks while generating false positives on legitimate traffic.
Moving Beyond Generic Solutions
Application security isn't set-and-forget infrastructure. It's an ongoing tuning effort that needs to keep pace with application changes.
"Applications are changing all the time, especially in modern DevOps environments," Medrano says. "Application updates, new features, new patterns, new customer workflows. All of that potentially changes on a day-to-day basis."
This means security tools need to be dynamic. They need to understand application behavior, not just match static patterns. They need to contextualize requests within application flows, not just examine individual transactions.
The most effective approach focuses on behavior rather than signatures. Instead of asking "Is this request malicious?" the question becomes "Does this request fit expected patterns for this application and user?"
What Actually Works in Production
Successful API security comes down to three principles:
Performance matters as much as protection. Security that slows down applications gets disabled. Security that blocks legitimate users gets bypassed. The only security that works is security that doesn't interfere with business operations.
Context beats patterns. Generic rules miss sophisticated attacks and generate false positives. Application-specific logic catches real threats while minimizing noise.
Gradual enforcement reduces risk. Instead of immediately blocking suspicious requests, effective systems track frequency and confidence. They might require additional authentication for borderline cases or temporarily limit functionality rather than completely blocking access.
"You can start by understanding how many times a particular pattern is detected," Medrano explains. "Account takeover attacks tend to happen at scale. You can focus on how many times you see that before you start blocking it from the same source."
The Real AI Problem
Every security vendor claims AI capabilities. Most deliver advanced analytics at best.
"You couldn't walk the floor without seeing AI somehow incorporated into the marketing," Medrano observes about Black Hat. "Many cases where AI is claimed, it's maybe just advanced analytics or machine learning."
The overhype creates two problems. Teams expect AI to solve problems it can't handle. And they ignore the areas where machine learning actually helps, like behavior analysis and pattern recognition.
Real AI value in security comes from automating analysis that previously required human expertise. Not replacing security teams, but giving them better tools to understand what's happening in their applications.
Building Security That Scales
The companies that get API security right don't start with tools. They start with principles. Security considerations get built into application design from the beginning. Security teams work closely with engineering throughout the development lifecycle.
This approach doesn't require massive budgets. It requires different thinking. Security becomes part of application architecture, rather than something bolted on afterward.
"Understanding that security done right from the beginning will save costs on the back end," Medrano notes. "It's not a matter of slowing down development. It's being conscious of what the threats might look like and how you address them directly into the application."
The organizations that will survive the next wave of API attacks aren't those with the most security tools. They're the ones that understand security as a fundamental part of application design.