Imperva Breach is Another Reminder That API Keys Alone Cannot Secure APIs

Imperva, a company that provides application security solutions, recently announced that they had experienced a data breach that exposed user’s email addresses, scrambled passwords, API keys, and SSL certificates. A quick glance at the company’s API Documentation reveals other concerning revelations that may highlight a pattern of surprisingly lax security for a company whose sole mission is to protect customer data.

Imperva offers a Cloud Web Application Firewall (WAF), which was formerly known as Incapsula. This product analyzes requests coming into applications and looks for suspicious or malicious activity, allowing customers to preemptively block bad actors. Imperva was notified by a third-party on August 20th that old Incapsula records were left exposed. The breach only affects records pre-Sept. 15, 2017. The company has since implemented a 90-day password expiration for the product and implemented forced password rotations. 

Users of the solution are being urged to take several measures as a result of the leak, and the company has provided a dedicated email for customers that need help with ensuring their accounts are up to date ( Specifically, Imperva is encouraging customers to change user account passwords for Cloud WAF, Implement Single Sign-On (SSO), Enable two-factor Authentication, Generate and upload new SSL certificate, and Reset API keys. That last bit is extra concerning because a quick glance at the company’s API documentation left ProgrammableWeb’s Editor-in-Chief David Berlind shocked that Imperva uses API keys as the only form of security on all of the company’s various APIs.

There was a time when this was acceptable, but most agree that 2019 isn’t it. ProgrammableWeb reached out to Imperva about this concern and is yet to hear back. 

Imperva's Authentication Documentation

Imperva has yet to outline the cause of the breach, so it is impossible to say how effective additional API security would have been at protecting application data. Incidents like this, however, are exactly why most API providers have moved toward more advanced API authentication models like OAuth. API keys are far too often leaked for anyone to rely on them as a sole means of protecting data. Janet Wagner wrote this for ProgrammableWeb all the way back in 2015:

“Public exposure of API Keys, cloud credentials, and other sensitive data is a serious problem that is happening more and more often. Developers are increasingly relying on cloud-based tools to automate building code and deployment of services, which is leading to far more instances of accidental public exposure of sensitive data.”

What is most concerning at this point is the apparent lack of concern for API security, not just among developers in general, but within the application security community. ProgrammableWeb published a series titled Understanding The Realities of API Security that is a great Resource for anyone looking to brush up on API security strategies and standards. 

Be sure to read the next Security article: Google Introduces New Bug Bounty Programs