OWASP API security – 7: Security misconfiguration



1: Broken object level authorisation

2: Broken user authentication

3: Excessive data exposure

4: Lack of resources & rate limiting

5: Broken function level Authorization

6: Mass assignment

7: Security misconfiguration

8: Injection

9: Improper assets management

10: Insufficient logging & monitoring


The security misconfiguration vulnerabilities cover a range of common security mistakes made when exposing services over the internet.  One important part to note is that a service’s default configuration can be a Security Misconfiguration.  Any information on or insight into a service may give an attacker valuable information that can be used to exploit the service.  HTTP servers may present version numbers in default response headers or bodies.  Intentionally calling the service with bad request data may return a stack trace that might give valuable information regarding libraries used by the application or file names and paths.

To prevent security misconfiguration exploits service owners must carefully examine the data returned by the service in all scenarios, success to failure, and ensure that all exposed services and their dependencies are up to date with the latest security fixes.

OWASP summary

Threat agents/attack vectors Security weakness Impacts
API specific : Exploitability 3 Prevalence 3 : Detectability 3 Technical 2 : Business specific
Attackers will often attempt to find unpatched flaws, common endpoints, or unprotected files and directories to gain unauthorized access or knowledge of the system. Security misconfiguration can happen at any level of the API stack, from the network level to the application level. Automated tools are available to detect and exploit misconfigurations such as unnecessary services or legacy options. Security misconfigurations can not only expose sensitive user data, but also system details that may lead to full server compromise.

Source: OWASP security misconfiguration

APIM context

One of the values of an APIM is to help protect the API from Security Misconfiguration exploits.  The APIM, when also configured correctly, will limit the types of calls that can be made to the service, remove and modify headers, modify the response body, ensure connections are secured, and replace responses based on status code.

Tyk approach

Limiting the scope of information returned by an API can be achieved with various Tyk features:

  • Response header manipulation to remove or modify API response headers that reveal implementation details.
  • Response body manipulation to remove or modify parts of the API response body that reveal implementation details.
  • TLS to help clients make sure they are connecting to the right service and encrypt the traffic.
  • Mutual TLS with both the clients and API helps ensure that only callers with explicitly whitelisted client certificates can connect to the endpoints.
  • Error templates allow serving a different response body based on status code and content type, which can help minimise the implementation details sent to the client.
  • CORS functionality allows the Tyk Gateway to limit API access to particular browser-based consumers.
  • Policy path-based permissions and the whitelist plugin prevent clients from accessing API endpoints using non-authorised HTTP methods. For example, blocking the use of the DELETE method on an endpoint which should only accept GET requests.
  • Tyk can be configured using environment variables, which take precedence over values in local configuration files. The use of environment variables can help standardise configuration across containerised deployments.
  • For GraphQL APIs:
    • Schema introspection ensures that the Tyk Dashboard automatically uses the schema of the upstream GraphQL API, and can keep it synchronised if it changes.
    • GraphQL schema validation prevents invalid schemas from being saved. This catches errors such as duplicate type names and usage of unknown types.
  • Third-party secret storage can be used to centralise configuration of sensitive data such as passwords. This data can then be dynamically referenced by Tyk configuration files, rather than hard coded.
  • Custom plugins for more complex cases, users can write custom plugins in a variety of languages, either directly or through gRPC calls, to implement their requirements.

APIM owners should schedule regular penetration tests to ensure the security of their published services. Tyk, through our professional services or partners, can assist in the process.