Uploaded image for project: 'Rules Repository'
  1. Rules Repository
  2. RSPEC-4529

Exposing HTTP endpoints is security-sensitive


    • Type: Security Hotspot Detection
    • Status: Deprecated
    • Resolution: Unresolved
    • Labels:
    • Message:
      Make sure that exposing this HTTP endpoint is safe here.
    • Default Severity:
    • Impact:
    • Likelihood:
    • Covered Languages:
      C#, Java, JavaScript, PHP, Python, VB.Net
    • Irrelevant for Languages:
      ABAP, Cobol, CSS, Flex, HTML, PL/I, PL/SQL, RPG, Solidity, Swift, T-SQL, VB.Net, VB6, XML
    • Remediation Function:
    • Constant Cost:
    • Analysis Scope:
      Main Sources
    • Common Rule:


      Exposing HTTP endpoints is security-sensitive. It has led in the past to the following vulnerabilities:

      HTTP endpoints are webservices' main entrypoint. Attackers will take advantage of any vulnerability by sending crafted inputs for headers (including cookies), body and URI. No input should be trusted and extreme care should be taken with all returned value (header, body and status code).

      This rule flags code which creates HTTP endpoint. It guides security code reviews to security-sensitive code.

      Ask Yourself Whether

      • an input is not sanitized before being used. This includes any value coming from the URI, header, body and cookies.
      • the response contains some unsafe data. for example the input could come from a database which contains user inputs. Check the response's headers, cookies, body and status code.
      • the response contains some sensitive information which the user shouldn't have access to.
      • no access control prevents attackers from successfully performing a forbidden request.
      • an attacker can get sensitive information by analyzing the returned errors. For example, a web service can expose the existence of user accounts by returning 403 (Forbidden) instead of 404 (Not Found) when an attacker ask for them.

      You are at risk if you answered yes to any of those questions.

      Recommended Secure Coding Practices

      Never trust any part of the request to be safe. Make sure that the URI, header and body are properly sanitized before being used. Their content, length, encoding, name (ex: name of URL query parameters) should be checked. Validate that the values are in a predefined whitelist. The opposite, i.e. searching for dangerous values in a given input, can easily miss some of them.

      Do not rely solely on cookies when you implement your authentication and permission logic. Use additional protections such as CSRF tokens when possible.

      Do not expose sensitive information in your response. If the endpoint serves files, limit the access to a dedicated directory. Protect your sensitive cookies so that client-side javascript cannot read or modify them.

      Sanitize all values before returning them in a response, be it in the body, header or status code. Special care should be taken to avoid the following attacks:

      Restrict security-sensitive actions, such as file upload, to authenticated users.

      Be careful when errors are returned to the client, as they can provide sensitive information. Use 404 (Not Found) instead of 403 (Forbidden) when the existence of a resource is sensitive.



          Issue Links

          Java RSPEC-4832 Language-Specification Active Unassigned
          C# RSPEC-4908 Language-Specification Active Unassigned
          VB.NET RSPEC-5031 Language-Specification Active Unassigned
          JavaScript RSPEC-5088 Language-Specification Active Unassigned
          PHP RSPEC-5094 Language-Specification Active Unassigned
          Python RSPEC-5235 Language-Specification Active Unassigned



              • Assignee:
                alexandre.gigleux Alexandre Gigleux
              • Votes:
                0 Vote for this issue
                2 Start watching this issue


                • Created: