# Top 10 2017-A10-Underprotected APIs

From OWASP

==The Top 10-2017 Wiki is under Construction. The Content is Not Finished yet.==
==Edits to this page will be lost. If you wish a change, please file an issue on GitHub. ==

← A9-Using Components with Known Vulnerabilities | 2017 Table of Contents 2017 Top 10 List | What's Next for Developers →

Threat Agents | Attack Vectors | Security Weakness | Technical Impacts | Business Impacts
--- | --- | --- | --- | ---
Application Specific | Exploitability AVERAGE | Prevalence COMMON | Detectability DIFFICULT | Impact MODERATE | Application / Business Specific
Consider anyone with the ability to send requests to your APIs. Client software is easily reversed and communications are easily intercepted, so obscurity is no defense for APIs. | Attackers can reverse engineer APIs by examining client code, or simply monitoring communications. Some API vulnerabilities can be automatically discovered, others only by experts. | Modern web applications and APIs are increasingly composed of rich clients (browser, mobile, desktop) that connect to backend APIs (XML, JSON, RPC, GWT, custom). APIs (microservices, services, endpoints) can be vulnerable to the full range of attacks. Unfortunately, dynamic and sometimes even static tools don’t work well on APIs, and they can be difficult to analyze manually, so these vulnerabilities are often undiscovered. | The full range of negative outcomes is possible, including data theft, corruption, and destruction; unauthorized access to the entire application; and complete host takeover. | Consider the impact of an API attack on the business. Does the API access critical data or functions? Many APIs are mission critical, so also consider the impact of denial of service attacks.

Am I Vulnerable To 'Underprotected APIs'? Testing your APIs for vulnerabilities should be similar to testing the rest of your application for vulnerabilities. All the different types of injection, authentication, access control, encryption, configuration, and other issues can exist in APIs just as in a traditional application. However, because APIs are designed for use by programs (not humans) they frequently lack a UI and also use complex protocols and complex data structures. These factors can make security testing difficult. The use of widely-used formats can help, such as Swagger (OpenAPI), REST, JSON, and XML. Some frameworks like GWT and some RPC implementations use custom formats. Some applications and APIs create their own protocol and data formats, like WebSockets. The breadth and complexity of APIs make it difficult to automate effective security testing, possibly leading to a false sense of security. Ultimately, knowing if your APIs are secure means carefully choosing a strategy to test all defenses that matter. | How Do I Prevent 'Underprotected APIs'? The key to protecting APIs is to ensure that you fully understand the threat model and what defenses you have: Ensure that you have secured communications between the client and your APIs. Ensure that you have a strong authentication scheme for your APIs, and that all credentials, keys, and tokens have been secured. Ensure that whatever data format your requests use, that the parser configuration is hardened against attack. Implement an access control scheme that protects APIs from being improperly invoked, including unauthorized function and data references. Protect against injection of all forms, as these attacks are just as viable through APIs as they are for normal apps. Be sure your security analysis and testing covers all your APIs and your tools can discover and analyze them all effectively.
Example Attack Scenarios Scenario #1: Imagine a mobile banking app that connects to an XML API at the bank for account information and performing transactions. The attacker reverse engineers the app and discovers that the user account number is passed as part of the authentication request to the server along with the username and password. The attacker sends legitimate credentials, but another user’s account number, gaining full access to the other user’s account. Scenario #2 Imagine a public API offered by an Internet startup for automatically sending text messages. The API accepts JSON messages that contain a “transactionid” field. The API parses out this “transactionid” value as a string and concatenates it into a SQL query, without escaping or parameterizing it. As you can see the API is just as susceptible to SQL injection as any other type of application. In either of these cases, the vendor may not provide a web UI to use these services, making security testing more difficult. | References OWASP OWASP REST Security Cheat Sheet OWASP Web Service Security Cheat Sheet External Increasing Importance of APIs in Web Development Tracking the Growth of the API Economy The API Centric Future The Growth of the API What Do You Mean My Security Tools Don’t Work on APIs?!! State of API Security

← A9-Using Components with Known Vulnerabilities | 2017 Table of Contents 2017 Top 10 List | What's Next for Developers →

© 2002-2017 OWASP Foundation This document is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. Some rights reserved.
Retrieved from "https://www.owasp.org/index.php?title=Top_10_2017-A10-Underprotected_APIs&oldid=228947"
Categories:

- OWASP Top Ten Project
- OWASP Top Ten 2017 Project