Salt Security Survey Shows Surge in API Attacks
Salt Security today published a quarterly report that found malicious application programming interface (API) traffic now accounts for 2.1% of all API traffic seen by its customers.
On average, those organizations were hit by 26.46 million malicious API calls for the month of June 2022, a more than 100% increase compared to the 12.22 million average malicious API calls per month experienced in 2021. A total of 44% of customers are now seeing an average of 11 to 100 attack attempts every month, with 34% seeing more than 100 attempts each month and 8% seeing more than a thousand. The attacks are increasing at a time when overall API traffic grew 168% over the past year, the report noted.
A separate survey of 350 IT and security professionals conducted by Salt Security found that 94% of respondents experienced security problems in production APIs in the past year, with 20% experiencing a data breach as a result of security gaps in APIs. A total of 61% of respondents also noted they now manage more than 100 APIs, and more than half (54%) reported they have delayed application rollouts because of API security concerns.
On the plus side, nearly two-thirds of respondents said API security has led to more cooperation among security and DevOps teams. Organizations are also making more frequent changes to APIs, with 11% of respondents updating APIs daily and 31% doing so weekly.
Michele McLean, vice president of marketing for Salt Security, said that while responsibility for API security in runtime environments lies primarily with security operations teams, there’s a clear need for more collaboration between those teams as organizations look to strike a balance between risk and the overall rate at which APIs are now being developed and deployed using DevSecOps best practices.
In general, a lack of clear-cut responsibility for API security is contributing to the challenges organizations are experiencing. More than half of respondents (53%) said they are focused on fixing gaps during development, with 59% specifically testing APIs. Only 30%, however, are identifying and remediating API security issues in runtime environments. Nearly a third of respondents (31%) admitted their organization experienced sensitive data exposure or a privacy incident within their API production environment over the past year. Nearly half (47%) said they identified vulnerabilities in production APIs while 38% experienced authentication problems.
The top API security concerns identified by respondents are not investing enough in pre-production security (20%) and not adequately addressing runtime security (18%), the survey found. The most concerning risks identified are zombie APIs that are no longer needed but are still accessible (41%) followed by account takeover (15%), accidental exposure of sensitive information (15%) and shadow or unknown APIs (11%).
A total of 61% of respondents admitted they lacked any or had only a basic API security strategy in place. Only 9% said they had an advanced API security strategy. A full 86% admitted they lacked confidence that their API inventory is complete, with 14% acknowledging they were unaware of which APIs exposed PII. Just over half of respondents (55%) said their security team focused on the threats identified by the OWASP API Security framework. The top reasons for a lack of a robust API strategy included budget (24%), expertise (20%), resources (19%) and time (11%).
The survey found most respondents relied on API gateways (54%) and web application firewalls (WAFs) (44%) to identify attacks, but 82% of respondents noted they did not believe their existing tools were very effective at preventing API attacks. The top required attributes of an API security platform identified by survey respondents were an ability to stop attacks (41%), the ability to identify which APIs expose personally identifiable information (PII) or sensitive data (40%) and meeting compliance or regulatory needs (39%).
There’s no doubt that APIs are becoming the focal point of more cyberattacks. The challenge is that, all too often, a lack of clear responsibility for defending this new class of endpoints often results in not enough attention being paid to a critical attack vector.
