How is API Security Different from General Application Security?

Although sometimes confused as the same, application security and API security are two distinct disciplines. Application security refers to securing entire applications, while API security refers to securing the APIs organizations use to connect applications and exchange data. As such, organizations must take different approaches to the two disciplines. 

What is application security? 

Application security (AppSec) uses authorization, encryption, and secure coding practices to protect data and systems from cyber-attacks. Organizations implementing AppSec reduce the risk of data breaches, protect sensitive data, and ensure their applications comply with industry standards. 

The ISACA defines the five critical components of AppSec programs as: 

1. Security by design
2. Secure code testing
3. Software bill of materials
4. Security training and awareness
5. WAFs and API security gateways and rule development

What is API security? 

API, or application programming interface, security protects APIs from cyber-attacks. API use has exploded in recent years, granting organizations opportunities for innovation by enabling data transfers between applications. Unfortunately, as API use has increased, so have the attacks launched upon them. Research from Salt Security revealed that attacks on APIs increased by 400% between June and December 2022. 

Application vs. API security threats 

Understanding the difference between AppSec and API security requires understanding each discipline’s top threats. Fortunately, OWASP, a non-profit organization seeking to improve software security, provides a comprehensive list of the most significant threats to application security and API security. Known as the OWASP Top Ten, the lists collate information from OWASP’s global security expert community to identify the most critical threats to applications and APIs. 

Interestingly, while OWASP published the Top Ten Web Application Security Risks list in 2003, it only released the Top Ten API Security Risks list in late 2019. This discrepancy represents another key difference between application and API security: application security is a well-established, extensively researched discipline that has undergone numerous evolutionary stages, whereas API security is not. 

While we don’t have time for an in-depth analysis, it’s worth briefly looking at each list to see how they differ, which should inform how organizations approach AppSec and API security. 

OWASP Top Ten Application Security Risks (2021)

1. Broken Access Control – When an unauthorized user can access restricted information or systems  
2. Cryptographic Failures – When a third party exposes sensitive data without specific intent due to a lack of or flaws in cryptography
3. Injection – When an attacker attempts to send data to an application in a way that will change the meaning of commands sent to an interpreter
4. Insecure Design – Risks related to architectural and design flaws
5. Security Misconfiguration – When security teams inaccurately configure or leave security controls insecure 
6. Vulnerable and Outdated Components – When organizations leave components unpatched 
7. Identification and Authentication Failures (née Broken Authentication) – When applications are vulnerable to authentication attacks
8. Software and Data Integrity Failures – When code and infrastructure fail to protect against integrity violations
9. Security Logging and Monitoring Failures (née Insufficient Logging and Monitoring) – When organizations fail to detect data breaches due to inadequate logging and monitoring procedures 
10. Server-Side Request Forgery – When attackers fool applications into sending a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL) 

OWASP Top Ten API Security Risks (2023)  

1. Broken Object Level Authorization – When an API object – for example, databases or files – do not have proper authorization controls, granting unauthorized users access 
2. Broken Authentication – When software and security engineers misunderstand the boundaries of API authentication and how to implement it 
3. Broken Object Property Level Authorization – A combination of excessive data exposure and mass assignment: when attackers exploit a lock of or improper authorization at the object property level.
4. Unrestricted Resource Consumption – Satisfying API requests requires network bandwidth, CPU, memory, and storage. Service providers make other resources such as emails/SMS/phone calls or biometrics validation available via API integrations and paid for per request. Successful attacks can lead to Denial of Service or increased operational costs.
5. Broken Function Level Authorization involves attackers sending legitimate API calls to exposed API endpoints
6. Unrestricted Access to Sensitive Business Flows – APIs vulnerable to this risk expose a business flow – such as buying a ticket or posting a comment – without compensating for how the functionality could harm the business if used excessively in an automated manner; this doesn’t necessarily come from implementation bugs.
7. Server-Side Request Forgery – When an API fetches a remote resource without validating the user-supplied URI; enabling an attacker to coerce the application to send a craftedrequest to an unexpected destination, even when protected by a firewall or a VPN.
8. Security Misconfiguration – APIs and the systems supporting them typically contain complex configurations to make them more customizable. Software and DevOps engineers can miss these configurations or don’t follow security best practices regarding configuration, opening the door for different types of attacks.
9. Improper Inventory Management – APIs expose more endpoints than traditional web applications, making proper and updated documentation important. An adequate inventory of hosts and deployed API versions also are essential to mitigate issues such as deprecated API versions and exposed debug endpoints.
10. Unsafe Consumption of APIs – Developers tend to trust data received from third-party APIs more than user input and adopt weaker security standards. To compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.

As you can see, while there is some overlap, applications and APIs are primarily subject to different, unique threats, and organizations must respond accordingly. The key difference between the two lists is that organizations can mitigate all the critical risks associated with application security with traditional, multi-purpose security tools and techniques, but API security is different. 

API security is a highly modern problem that requires an equally modern solution. Organizations cannot expect the tools they employ to protect their applications and other assets to meet the task of securing APIs. API security requires API-specific security tools; traditional protection methods such as API gateways and Web Application Firewalls (WAFs) don’t go far enough.