Security warnings in API requests
You can use Postman to identify any potential security risks your API might be vulnerable to.
- Security misconfiguration
- Broken user authentication
- Excessive data exposure
- Injection
- Cross-site scripting
Security misconfiguration
A security misconfiguration can result from many issues, including:
- Overly permissive cross-origin resource sharing (CORS)
- Insecure default configurations
- Incomplete or ad-hoc configurations
- Open cloud storage
- Misconfigured HTTP headers
- Unnecessary HTTP methods
- Verbose error messages that contain sensitive information
CORS misconfiguration
Cross-origin resource sharing (CORS) is a browser mechanism that enables controlled access to resources located outside of a given domain. It extends and adds flexibility to the same-origin policy (SOP). However, if a website’s CORS policy isn’t configured and implemented correctly, it also provides the potential for cross-domain attacks. CORS doesn’t protect from cross-origin attacks such as cross-site request forgery (CSRF).
Allowlisted null origin value with credentials
Allowlisted null origin value
Allowed all origins using a wildcard value
Unencrypted communication
Some websites accept a connection through HTTP and then redirect to HTTPS. In those cases, visitors might first communicate with the non-encrypted version of the site (for example, www.example.com or example.com) before they’re redirected. This creates an opportunity for a manipulator-in-the-middle attack. The redirect could be exploited to direct visitors to a malicious site instead of the secure version of the original site.
Cache poisoning
Cache poisoning attacks exploit Cache-Control behavior so that a harmful response is served to users. If a maliciously constructed response is cached, either by a web cache used by multiple users or in the browser cache of a single user, the damage can be magnified.
Cross-site request forgery
Cookies aren’t sent on typical cross-site subrequests (for example, to load images or frames into a third party site). However, cookies are sent when a user navigates to the origin site (in other words, when they follow a link).
Sensitive cookie with improper SameSite attribute
Broken user authentication
If an authentication mechanism is implemented incorrectly, attackers might be able to compromise authentication tokens or exploit implementation flaws to assume other user’s identities temporarily or permanently. When a system’s ability to identify the user is compromised, the overall security of an API is compromised.
Authentication data exposure over unsecured protocol
No authentication
Excessive data exposure
Sometimes developers expose all object properties without considering their sensitivity. As they look forward to generic implementations of their API, they rely on clients to perform the data filtering before displaying it.
Information exposure
Sometimes an API can inadvertently share sensitive information like the location of the file that produced an unhandled exception. This information can be used to launch more attacks on a web application.
Bad actors might provide invalid inputs to the API to get more information about the underlying system that’s being used to power the API. If the invalid inputs aren’t handled correctly, the API will return the stack trace of the error. The stack trace includes the error origin, packages used in the service, the server’s directory path, and information about the technology used to build the API.
Stack trace leak
Sensitive data exposure in response body
Private IP exposure
Information exposure in URL
If information is exposed in a URL, attackers can use it to access sensitive information like usernames, passwords, and API tokens.
Information exposure in URL query parameters key
Sensitive data exposure in URL
Injection
Injection flaws such as SQL, NoSQL, and command injection can occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into running unintended commands or accessing data without proper authorization.
SQL injection
SQL injection is a common attack vector that uses malicious SQL code for database manipulation to access information that wasn’t intended to be displayed. This information might include sensitive information like company data, user lists, or private customer details.
Cross-site scripting
Cross-Site scripting (XSS) attacks are a type of injection in which a malicious script is injected into a trusted website. XSS attacks occur when an attacker uses a web application to send malicious code, most often a browser-side script, to a different user.
Sensitive cookie without HttpOnly flag
The HttpOnly flag is included in a Set-Cookie HTTP response header. Use the HttpOnly flag when generating a cookie to help mitigate the risk of client-side script accessing the protected cookie.
Sensitive cookie without secure flag
The browser won’t send a cookie with the Secure attribute set over an unencrypted HTTP request.
By setting the Secure attribute, the browser will prevent the transmission of a cookie over an unencrypted channel.
Clickjacking
Clickjacking is when an attacker uses transparent layers to trick a user into clicking a button or link on another page when they meant to click the top-level page. Clickjacking is also known as a “UI redress attack.” This enables the attacker to hijack clicks meant for one page and route them to another page owned by another application, domain, or both.