Security warnings in API requests

You can use Postman to identify any potential security risks your API might be vulnerable to.

• Security misconfiguration
  • CORS misconfiguration
    • Allowlisted null origin value with credentials
    • Allowlisted null origin value
    • Allowed all origins using a wildcard value
  • Unencrypted communication
  • Cache poisoning
  • Cross-site request forgery
    • Sensitive cookie with improper SameSite attribute
• Broken user authentication
  • Authentication data exposure over unsecured protocol
  • No authentication
• Excessive data exposure
  • Information exposure
    • Stack trace leak
    • Sensitive data exposure in response body
  • Private IP exposure
  • Information exposure in URL
    • Information exposure in URL query parameters key
    • Sensitive data exposure in URL
• Injection
  • SQL injection
• Cross-site scripting
  • Sensitive cookie without HttpOnly flag
  • Sensitive cookie without secure flag
  • Clickjacking
    • Improper frame-ancestors directive in CSP policy
    • Misconfigured X-Frame-Options header
  • MIME sniffing

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

Issue description

Possible fix

Access-Control-Allow-Credentials is set as true and Access-Control-Allow-Origin is set as null. With this configuration, an attacker could send AJAX queries to a vulnerable website from a malicious page loaded by the victim's user agent. Even if a website with unauthenticated sensitive content (for example, an intranet website) doesn't allow authenticated AJAX requests, this misconfiguration still lets attackers access it.

If a web resource has sensitive information, you need to specify the origin in the Access-Control-Allow-Origin header. Specify trusted websites that need this resource in this header, with the most secured protocol supported.

Allowlisted null origin value

Issue description	Possible fix
If the null origin is allowlisted, an attacker can use various tricks to generate a cross-origin request with the value null in the Origin header. This will satisfy the allowlist, leading to cross-domain access.	If a web resource has sensitive information, you need to specify the origin in the Access-Control-Allow-Origin header. Only specify trusted websites that need this resource in this header, with the most secured protocol supported.

Allowed all origins using a wildcard value

Issue description	Possible fix
Access-Control-Allow-Origin is set as the wildcard value (*). This means that the resource can be accessed by any origin.	Make sure that sensitive data isn't available in an unauthenticated way (for example, by using IP address allowlisting). To enable the web browser to enforce the Same Origin Policy (SOP) in a more restrictive way, configure the Access-Control-Allow-Origin HTTP header to a restricted set of domains, or remove all CORS headers entirely.

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.

Issue description	Possible fix
The HTTP Strict-Transport-Security header is missing or isn't configured correctly. This header informs browsers to access the site using HTTPS and that any future attempts to access it using HTTP will automatically be converted to HTTPS.	Add the Strict-Transport-Security header so the browser can remember to access the site using HTTPS, and define the max-age property in the header.

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.

Issue description	Possible fix
The Cache-Control header is missing or isn't configured correctly, which means the browser and proxies can cache content. This might be the intended behavior for static assets like CSS, JavaScript, or image files, but you need to review the assets to ensure that sensitive content won't be cached.	For secure content, make sure the Cache-Control header is set with no-cache, no-store, and must-revalidate. If an asset needs to be cached, consider setting the directives public, max-age, and immutable.

Cross-site request forgery

Cookies aren't sent on typical cross-site sub-requests (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

Issue description	Possible fix
A cookie with SameSite set to None isn't using the Secure attribute. This means an attacker could access the cookie by simulating a XSS attack on the client.	To prevent a cookie with SameSite=None from being accessed by an XSS attack, use the Secure 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

Issue description	Possible fix
Authentication credentials can be leaked over an unsecured protocol. An attacker can intercept the request and access these credentials.	Use the HTTPS protocol to encrypt the traffic transported on the network.

No authentication

Issue description	Possible fix
No authentication scheme is being used to authenticate the user's identity. An attacker can misuse the API to exploit the system.	Use an authentication strategy (like OAuth, OpenID Connect, API key, or HTTP) to verify the user's identity.

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

Issue description	Possible fix
The stack trace is exposed in the response body. This might reveal the structure of the application and any internal components it relies on. It might also reveal information like server-side file names and SQL code that the application uses, which means an attacker could fine-tune a later injection attack.	Send the user a more generic error message that reveals less information. Either suppress the stack trace entirely, or log it specifically to the server.

Sensitive data exposure in response body

Issue description	Possible fix
The response body looks like it has sensitive information. An attacker could use this information to steal other users' identities or perform fraudulent financial transactions. This also violates payment card industry (PCI) security standards and most organizational compliance policies.	Trim sensitive information from the response.

Private IP exposure

Issue description	Possible fix
There is a private IP address (such as 10.x.x.x, 172.x.x.x, 192.168.x.x) in the HTTP response body. An attacker could use this information to target internal systems.	Remove the private IP address from the HTTP response body. For comments, use JSP, ASP, or PHP comments instead of HTML or JavaScript comments, which can be seen by client browsers.

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

Issue description	Possible fix
This request looks like it has sensitive information in the URL. An attacker could exploit this sensitive information.	Avoid using sensitive information (like API keys, access tokens, auth credentials, usernames, and passwords) in URLs since they can be captured in web server logs. Use body and headers for this information.

Sensitive data exposure in URL

Issue description	Possible fix
This request looks like it has sensitive information in the URL. An attacker could exploit this sensitive information.	Avoid using sensitive information (like API keys, access tokens, auth credentials, usernames, and passwords) in URLs since they can be captured in web server logs. Use body and headers for this information.

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 executing 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.

Issue description	Possible fix
The SQL error stack trace is exposed in the response body. This means an attacker could interfere with the queries that an application makes to its database. An attacker might also be able to view data that they wouldn't typically be able to retrieve.	SQL injection can be prevented by using parameterized queries (also known as prepared statements) instead of string concatenation within a query.

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.

Issue description	Possible fix
A cookie was set without the HttpOnly flag, which means the cookie can be accessed by JavaScript. If attackers run a malicious script on this page, then they can access the cookie and send it to another site. If this is a session cookie, session hijacking may be possible.	Set the HttpOnly flag for all cookies.

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.

Issue description	Possible fix
A cookie was set without the Secure flag. This means an attacker could access the cookie using an unencrypted connection.	If there is sensitive information in a cookie or the cookie is a session token, ensure that it's passed using an encrypted channel and that the Secure flag is set.

Clickjacking

Clickjacking is when an attacker uses transparent layers to trick a user into selecting a button or link on another page when they meant to select 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.

Improper frame-ancestors directive in CSP policy

Issue description	Possible fix
The HTTP Content-Security-Policy (CSP) frame-ancestors directive is set to *. This means all websites can load other websites in an iframe. This might make the website vulnerable to clickjacking.	Specify a specific origin to allowlist the trusted origins instead of allowing all origins in Content-Security-Policy.

Misconfigured X-Frame-Options header

Issue description	Possible fix
The X-Frame-Options header is set to Allow. This means all websites can load other websites in an iframe. This might make the website vulnerable to clickjacking.	Specify the frame-ancestors directive with a specific origin to allowlist the trusted origins instead of allowing all origins in Content-Security-Policy.

MIME sniffing

Issue description	Possible fix
The X-Content-Type-Options header isn't configured correctly. This means an attacker could upload a HTML file disguised as a different file type that the web server accepts (for example, a JPEG or a zip file). The browser renders the uploaded file as an HTML file, then the attacker can execute an XSS attack.	To turn off MIME sniffing in Internet Explorer and Chrome, use the X-Content-Type-Options: nosniff HTTP header. This requires the browser to use the MIME type sent by the server. Since the browser will no longer analyze the file, the website owner must make sure that they're sending the appropriate MIME information.