Think about all the personal, financial, and corporate data we entrust to web apps today. Stopping to wonder who’s protecting it—or whether it’s protected at all—can be a sobering experience.

On a typical day, I might head to the airport for a business trip. When I get there, I’ll pay for parking, check in to my flight, peruse the headlines, grab coffee, check my Slack, Twitter, and Facebook notifications, and review some pull requests. All with my phone. All online.

The web apps I use to perform all these functions may or may not be protected from the plethora of web application security threats they face. Are frameworks up to date, libraries patched, code reviewed for security? Do the organizations building and deploying these apps continually monitor for new CVEs, review external libraries, perform static and dynamic analysis, and fix insecure defaults? And if attackers make it past network perimeters, are these apps vulnerable to SQL injections, cross-site scripting attacks, authentication attacks, and brute forcing?

We often consider web security from an end user perspective, and for good reason, as the above examples show. Any of the app security threats mentioned above can and do cause sensitive user data, including financial and health information, to fall into malicious hands. As a result, organizations that develop and distribute web apps have just as much reason as end users to worry about web app security. Nothing less than the integrity of the business is at stake.

Web Application Security Is Hard—but Recovering from a Breach is Harder

Many companies building web apps today are working at a pace that even a few years ago would have been unthinkable. Agile development processes and DevOps have brought about whole new ways of thinking of how software is conceptualized, developed, tested, and deployed. Code that in previous years would have been considered unfinished is now moving into production as organizations struggle to stay agile.

What’s more, traditional methods of securing code as it goes through production aren’t up to the challenges presented by modern security threats. For example, code scanning tools that offer workarounds for known vulnerabilities don’t do a thing to protect against vulns that have yet to be publicized. And Web Application Firewalls (WAFs) are signature-based, difficult to maintain, and relatively simple for attackers to bypass.

Once the bad guys have made it inside your organization’s network perimeter, if you’re mainly using these traditional methods to protect your web apps, it may already be too late to prevent them from pilfering sensitive user or account data. The damage to your organization’s reputation from a successful breach is hard to quantify.

The Solution: Letting Apps Protect Themselves

Protection that originates inside the app is much more targeted, with fewer false positives. Here are some specific examples of approaches your organization can take to protect apps from the inside:

• Don’t allow uploaded images to execute as code. Apps don’t need to read or write anywhere inside /etc. In fact, apps shouldn’t write anywhere except /tmp and /var/log.
• Track shell code execution. Most apps don’t need to execute shell commands—fence them off! If for some reason your apps do need to do this, be sure to track the code that runs the commands. Commands that send invoices, for example, should not be opening reverse shells to Russia!

The bottom line? Traditional approaches like Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) were designed to fix vulnerabilities that arise long before users are exposed to software. They don’t work well with continuous release cycles, where time to deployment is critical. And WAFs were never designed to guard against unknown, newly-emerging threats.

To get more specific tips on protecting against emerging threats to web applications in real time, download our white paper, Real-Time Web Application Security.