Before start reading OWASP API Security Top 10 in details. you can check APIs for non-technical people if you have no technical background.

What is API

API Stands for Application Program Interface. APIs are a set of functions and procedures that allow for the creation of applications that access data and features of other applications, services or operating systems. And in this blog, I’ll demonstrate OWASP API Security Top 10 2019.

Non-technical explanation of an API

The simplest way, APIs are connectors. It’s all about connecting different technologies and 3rd party products and software to our product, For more details check my blog APIs For Non-Technical People.

APIs Deep Dive

By nature, APIs expose application logic and sensitive data such as Personally Identifiable Information (PII). So that, APIs have increasingly become a target for attackers. Without secure APIs, Rapid innovation would be impossible.

APIs Is Used In

• Banking.
• Retail.
• Transportation.
• Autonomous vehicles.
• Smart cities.
• Mobile, Saas and Web applications.
• IOT different applications.
• And more…….

The Primary Goal of the OWASP API Security Top 10 – 2019

To educate those involved in API development and maintenance, for example

• Developers
• Designers
• Managers and business owners.

API Security Risk

• Exploitability: 3 means it’s easy to be exploited.
• Weakness Prevalence: 3 means it’s widely spread and well known to attackers.
• Weakness Detectability: 3 means that it’s easy to detect this attack from the app/system admin side.
• Technical Impact: 3 means it has a high impact (very risky).
• Business Impact: Describe the business and legal impact.

OWASP API Security Top 10 2019 – Top 10 API Attacks

API1:2019 Broken Object Level Authorization

Object-level authorization is an access control mechanism. It is usually implemented at the code level. to validate that one user can only access objects that they should have access to.

• Every API endpoint that receives an ID of an object.
• The API endpoint needs to perform any type of action on this object.
• Before taking any action, It performs object-level authorization checks.
• These checks should validate that this logged-in user does have access to perform the requested action on the requested object.
• Failures in this mechanism lead to unauthorized information disclosure, modification, or destruction of all data.

Simple Example and Business Impact:

Normal users cannot access the admin dashboard.

A normal user may access the admin dashboard, gain access to admin info which is unauthorized information disclosure. Moreover, the attacker may be able to modify, create or delete information.

Scenario 1:

• While monitoring network traffic, The attacker found custom HTTP request header contains x-user-id: 54796
• By replacing the x-user-id value to be 54795, The attacker becomes able to modify the user’s account data.

Scenario 2:

• An eCommerce platform for online stores provides a listing page with revenue charts for their hosted shops.
• Inspecting web browser (ex: Chrome), an attacker can identify the API endpoints used as a data source for those charts.
• The API pattern is like /shops/{shopName}/revenue_data.json.
• By changing the {shopName}, The attacker can access other shops’ revenue charts.

How To Prevent?

• Implement a proper authorization mechanism that relies on user policies and hierarchy.
• Use an authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database.
• Prefer to use random and unpredictable values as GUIDs for records’ IDs. Check this GUIDs generator.
• Test after every change in your code.

API2:2019 Broken User Authentication

• Permits credential stuffing whereby the attacker has a list of valid usernames and passwords.
• Allow attackers to perform a brute force attack on the same user account, without presenting a captcha/account lockout mechanism.
• Permits weak passwords. (No password policy)
• Sends sensitive authentication details, such as auth tokens and passwords in the URL.
• It doesn’t validate the authenticity of tokens.
• Accepts unsigned/weakly signed JWT tokens (“alg”:”none”)/don’t validate their expiration date.
• Uses plain text, encrypted, or weakly hashed passwords.
• Uses weak encryption keys.

Scenario #1

Credential stuffing (using lists of known usernames/passwords), is a common attack. If an application does not implement automated threat or credential stuffing protection, the application can be used as a password tester to determine if the credentials are valid.

Scenario #2

An attacker starts the password recovery workflow by issuing a POST request to
/api/system/verification-codes and by providing the username in the request body. Then, an SMS token with 6 digits is sent to the victim’s phone.

Because the API doesn’t implement a rate-limiting policy. Therefore, the attacker can test all possible combinations using a multi-threaded script, against the /api/system/verification-codes/{smsToken} endpoint to discover the right token within a few minutes.

How to Prevent?

• Make sure you know all the possible flows to authenticate to the API (mobile/ web/deep links that implement one-click authentication/etc.)
• OAuth is not authentication, and neither is API keys.
• Don’t reinvent the wheel in authentication, token generation, password storage. Use the standards and a well-known authentication framework.
• Credential recovery/forget password endpoints should be treated as login endpoints in terms of brute-force, rate limiting, and lockout protection.
• Use the OWASP Authentication Cheatsheet.
• Where possible, implement multi-factor authentication.
• Implement anti brute force mechanisms to mitigate credential stuffing, dictionary attack, and brute force attacks on your authentication endpoints.
• The above mechanism should be stricter than the regular rate-limiting mechanism on your API.
• Implement account lockout/captcha mechanism to prevent brute force against specific users.
• Implement weak-password checks. (Password policy)
• API keys should not be used for user authentication, but for client app/project authentication.

API3:2019 Excessive Data Exposure

API sends/expose excessive data (more objects than needed), then the frontend logic handles data filtration.

Scenario #1:

• The mobile team uses the /api/articles/{articleId}/comments/{commentId} endpoint in the articles view to render comments metadata.
• Sniffing the mobile application traffic, an attacker finds out that other sensitive data related to comment’s author is also returned. The endpoint implementation uses a generic toJSON() method on the User model, which contains PII, to serialize the object.

Scenario #2

• IOT based surveillance system allows the system admin to add new accounts for security guards with different permissions.
• Once the security guard uses his mobile app, an API call is triggered to: /api/sites/111/cameras in order to receive data about the available cameras and show them on the dashboard.
• The response contains a list with details about cameras in the following format: {“id”:”xxx”,”live_access_token”:”xxxxbbbbb”,” building_id”:”yyy”}.
• The Frontend logic filters the response and only shows specific cameras, but the API response contains all cameras.

How to Prevent?

• Never rely on the client-side to filter sensitive data. (Do the logic in the backend)
• Review the responses from the API to make sure they contain only legitimate and specific data.
• Avoid using generic methods such as to_json() and to_string().
• Classify sensitive and personally identifiable information (PII) that your application stores and works with, reviewing all API calls returning such information to see if these responses pose a security issue.
• Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism define and enforce data returned by all API methods, including errors.

API4:2019 Lack of Resources & Rate Limiting

• Exploitation may lead to DoS(Denial of Service),making the API unresponsive or even unavailable.
• API requests consume resources such as network,CPU, memory, and storage.

An API is vulnerableif at least one of the following limits is missing:

• Execution timeouts
• Max allocable memory
• Number of file descriptors
• Number of processes
• Request payload size (e.g., uploads)
• Number of requests per client/resource
• Number of records per page to return in a singlerequest response

Scenario #1

An attacker uploads a large image by issuing a POST requestto /api/v1/images.When the upload is complete, the API creates multiple thumbnails with differentsizes. Due to the size of the uploaded image, available memory is exhaustedduring the creation of thumbnails and the API becomes unresponsive.

Scenario #2

• We have an application that contains the users’list on a UI with a limit of 200 users per page.
• The users’ list is retrieved from the serverusing the following query: /api/users?page=1&size=100. An attacker changesthe size parameter to 200 000, causing performance issues on the database.
• Meanwhile, the API becomes unresponsive and isunable to handle further requests from this or any other clients (aka DoS).
• The same scenario might be used to provokeInteger Overflow or Buffer Overflow errors.

How to Prevent?

• Implement Client limitations to API calling
• Notify the client when the limit is exceeded byproviding the limit number and the time at which the limit will be reset.
• Add proper server-side validation for querystring and request body parameters that controls the number of records to bereturned in the response.
• Define and enforce maximum size of data on allincoming parameters and payloads such as maximum length for strings and maximumnumber of elements in arrays.
• You may rely on DevOps deployment (Docker, Openshift or Kubernetes)
• Docker makes it easy to limit memory, CPU,number of restarts, file descriptors, and processes.

API5:2019 Broken Function Level Authorization

Exploitation requires the attacker to send legitimate APIcalls to the API endpoint that they should not have access to. (e.g., replacingthe HTTP method from GET to PUT, or changing the “users” string in the URL to“admins”).

To find a broken function level authorization:

• Can regular user access administrativeendpoints?
• Can a user perform sensitive actions (e.g.,creation, modification, or erasure) that they should not have access to bysimply changing the HTTP method (e.g., from GET to DELETE)?
• Can a user from group X access a function thatshould be exposed only to users from group Y, by simply guessing the endpointURL and parameters (e.g., /api/v1/users/export_all)?

Scenario #1

During the registration process to an application thatallows only invited users to join, the mobile application triggers an API callto GET/api/invites/{invite_guid}. The response contains a JSON with detailsabout the invite, including the user’s role and the user’s email.

An attacker duplicated the request and manipulated the HTTPmethod and endpoint to POST /api/invites/new. This endpoint should only beaccessed by administrators using the admin console, which does notimplement function level authorization checks. The attacker exploits the issueand sends himself an invite to create an admin account:

POST /api/invites/new

{“email”:”hugo@malicious.com”,”role”:”admin”}

How to Prevent?

• The enforcement mechanism(s) should deny allaccess by default.
• Make sure that all of your administrativecontrollers inherit from an administrative abstract controller that implementsauthorization checks based on the user’s group/role, and keep in mind thebusiness logic of the application.

API6:2019 Mass Assignment

Exploitation usually requires an understanding of thebusiness logic, objects’ relations, and the API structure.

Objects in modern applications might contain manyproperties. Some of these properties should be updated directly by the client(e.g., user.first_nameor user.address)and some of them should not (e.g., user.is_vip flag).

An API endpoint is vulnerable if it automatically convertsclient parameters into internal object properties, without considering thesensitivity and the exposure level of these properties. This could allow anattacker to update object properties that they should not have access to.

Scenario #1:

A ride sharing application provides a user the option toedit basic information for their profile. During this process, an API call issent to PUT/api/v1/users/me with the following legitimate JSON object:

• {“user_name”:”inons”,”age”:24}The request GET/api/v1/users/me includes an additional credit_balance property:
• {“user_name”:”inons”,”age”:24,”credit_balance”:10}.

The attacker replays the first request with the followingpayload:

• {“user_name”:”attacker”,”age”:60,”credit_balance”:99999}

Since the endpoint is vulnerable to mass assignment, theattacker receives credits without paying.

Scenario #2:

A video sharing portal allows users to upload content anddownload content in different formats. An attacker who explores the API foundthat the endpoint GET /api/v1/videos/{video_id}/meta_data returns a JSONobject with the video’s properties. One of the properties is

• “mp4_conversion_params”:”-vcodech264″, which indicates that the application uses a shell command toconvert the video.

The attacker also found the endpoint POST /api/v1/videos/new isvulnerable to mass assignment and

allows the client to set any property of the video object.

• The attacker sets a malicious value as follows: “mp4_conversion_params”:”-vcodec h264 && format C:/”. This value will cause a shell

Command injection once the attacker downloads the video asMP4.

How to Prevent?

• Whitelist only the properties that should beupdated by the client.
• Use built-in features to blacklist propertiesthat should not be accessed by clients.
• If possible, avoid using functions thatautomatically bind a client’s input into code variables or internal objects.
• If applicable, explicitly define and enforceschemas for the input data payloads.

API7:2019 Security Misconfiguration

Attackers will often attempt to find unpatched flaws or unprotected files and directories to gain unauthorized access.

Security misconfigurations can not only expose sensitiveuser data, but also system details that may lead to full server compromise.

• The latest security patches are missing, or the systems are out of date.
• Unnecessary features are enabled (e.g., HTTP verbs).
• Transport Layer Security (TLS) is missing.
• Security directives are not sent to clients (Check for more info Security Headers).
• A Cross-Origin Resource Sharing (CORS) policy is missing or improperly set. ( check for more info)
• Error messages include stack traces, or other sensitive information is exposed.

Scenario #1

To target a specific service, an attacker uses a popular search engine to search for computers directly accessible from the Internet. The attacker found a host running a popular database management system, listening on the default port. Then, the host was using the default configuration, which has authentication disabled by default, and the attacker gained access to millions of records with PII, personal preferences, and authentication data.

How to Prevent?

• Repeatable hardening.
• Review and update configurations across the entire API stack.
• A secure communication channel for all API interactions accesses to static assets (e.g., images).

API8:2019 Injection

Attackers will feed the API with malicious data.

Injection flaws are very common and are often found in SQL,LDAP, or NoSQL queries, OS commands, XML parsers, and ORM.

Injection can lead to information disclosure and data loss.It may also lead to DoS, or complete host takeover.

Scenario #1:

We have an application with basic CRUD functionality foroperations with bookings. An attacker managed to identify that NoSQL injectionmight be possible through bookingId query string parameter in the delete bookingrequest. This is how the request looks like:

• DELETE /api/bookings?bookingId=678.

The API server uses the following function to handle delete requests:router.delete('/bookings', async function (req, res, next) {     try {         const deletedBooking = await Bookings.findOneAndRemove({_id' :          req.query.bookingId});         res.status(200);     } catch (err) {         res.status(400).json({         error: 'Unexpected error occured while processing a request'         });      }});

constdeletedBooking = await Bookings.findOneAndRemove({_id’ : req.query.bookingId});

res.status(200);

The attacker intercepted the request and changed the booking query string parameter as shown below. In this case, the attacker managed to delete another user’s booking:

DELETE/api/bookings?bookingId

[$ne]=678

How to Prevent?

• Validate, filter, and sanitize allclient-provided data, or other data coming from integrated systems.
• Special characters should be escaped using thespecific syntax for the target interpreter.
• Prefer a safe API that provides a parameterizedinterface.
• Always limit the number of returned records toprevent mass disclosure in case of injection.

API9:2019 Improper Assets Management

Old API versions are usually unpatched and are an easy wayto compromise systems.

Outdated documentation makes it more difficult to findand/or fix vulnerabilities. Lack of assets inventory and retire strategies

The API might bevulnerable if:

• The purpose of an API host is unclear, and thereare no explicit answers to the following questions:
• Which environment is the API running in (e.g.,production, staging, test, development)?
• Who should have network access to the API (e.g.,public, internal, partners)?
• Which API version is running?
• What data is gathered and processed by the API(e.g., PII)?
• What’s the data flow?
• There is no documentation, or the existingdocumentation is not updated.
• There is no retirement plan for each APIversion.
• Hosts inventory is missing or outdated.
• Integrated services inventory, either first- orthird-party, is missing or outdated.
• Old or previous API versions are runningunpatched.

Scenario #1

After redesigning their applications, a local search serviceleft an old API version (api.someservice.com/v1) running, unprotected, and withaccess to the user database. While targeting one of the latest released applications,an attacker found the API address (api.someservice.com/v2).

Replacing v2 with v1 in the URL gave the attacker access to the old, unprotected API, exposing the personally identifiable information (PII) of over 100 Million users.

How to Prevent?

• Inventory all API hosts and document importantaspects of each one of them.
• Inventory all integrated services and documentimportant aspects.
• Document all aspects of your API such asauthentication, errors, redirects, rate limiting, cross-origin resource sharing(CORS) policy and endpoints.
• Use external protection measures such as APIsecurity firewalls for all exposed versions of your APIs.
• Avoid using production data with non-productionAPI deployments.

API10:2019 Insufficient Logging & Monitoring

Without logging and monitoring, or with insufficient loggingand monitoring, it is almost impossible to track suspicious activities.

Scenario #1

Access keys of an administrative API were leaked on a public repository. The repository owner was notified by email about the potential leak but took more than 48 hours to act upon the incident. And access keys exposure may have allowed access to sensitive data. Due to insufficient logging, the company is not able to assess what data was accessed by malicious actors.

How to Prevent?

• Rely on a log management system.
• Log all actions.
• Logs should be handled as sensitive data, and their integrity should be guaranteed at rest and transit.
• Moreover, We need to configure a monitoring system to continuously monitor the infrastructure, network, and the API functioning.

You can check OWASP Logging CheatSheet

Thank you for reading!