APIs are at the heart of modern applications and have quickly become a favorite target of attackers. And for good reason - they expose a wealth of functionality and attack surface that is often poorly defended. In our previous article we introduced the key building blocks of API security that can help ensure your APIs get the same level of protection as the web front-end of your application.
APIs have altered the attack surface of modern applications and exposed new gaps in security in the process. In the old days, virtually all application traffic passed through the web front-end of an application, and unsurprisingly that is where security efforts were focused. APIs have quickly and thoroughly eroded this basic assumption.
The term “next-generation” gets thrown around a lot in security. Marketers have overused the term to the point that, for many, it has become an empty buzzword used to describe virtually anything. On the other hand, technology does go through major transformational changes where new approaches are needed to replace the old ways of doing things. The rise of next-generation firewalls (NGFWs), which replaced the old port-based firewalls are a classic example of this sort of transformation.
Last week we had a great webcast and discussion on the topic of securing APIs and microservice architectures. Based on the feedback during the webcast and the many conversations we have with prospects, this is becoming a very hot topic (and source of frustration) for many of you in application security.
This shouldn’t come as a surprise given that these two topics are shifting some of the fundamental assumptions that old-school WAFs have relied on for years. Instead of everything coming in through the front door, applications are increasingly accessed via APIs that can be both Internet-facing, as well as connected on the back-end. Likewise, as applications become more modular and broken into microservices, the old appliance-based model of WAFs is increasingly out of the loop in terms of seeing and enforcing application traffic.
Many of the questions we received in the webinar mirrored questions and challenges we regularly hear in the field when engaging with AppSec teams. So with that in mind, I wanted to quickly run through, and provide answers to, some of those questions.
As I talk to customers around the world about securing their applications I've noticed a specific topic keeps coming up more and more often: Securing their APIs - both public and internal varieties. RESTful JSON APIs seem to be the most prevalent these days, but I still hear about SOAP and XML APIs, as well as some customers on the bleeding-edge with GraphQL APIs they want to protect.
Let's talk about the future of application security. For those of us who have been designing network and application security architectures in the past couple decades it's been impossible to notice the pace of change has accelerated in the last few years. Static, legacy architectures are giving way to dynamic, auto-scaled microservices architectures. But can we continue to secure applications developed with CI/CD pipelines using legacy approaches?
We need to face reality - web application protection is incredibly challenging in the agile, cloud-based world in which businesses operate. Many organizations focus their security strategy on the applications themselves - a never-ending pattern of "patch and pray." Trying to successfully guide applications through the barrage of attacks, multiple technologies, and growing sophistication of attackers is like trying to follow an obscure map. You can see your final destination, but there are new obstacles to face every hour. This fact, coupled with the frustration with the limited intelligence of legacy WAFs, has created overburdened security teams and "firewall fatigue."