Security definitions uses basic auth misconfiguration detected in code

Rule Details

Cortex AppSec Rule ID	APPSEC_OPENAPI_13
Category - Subcategory	Public Exposure - APIs
Provider	OTHER
Severity	HIGH
Framework	OpenAPI

Impact

This rule checks to ensure that security definitions in a version 2.0 file do not use basic authentication. Using basic authentication is predominantly not considered a secure practice as it involves sending user credentials (username and password) in an unencrypted form over the network. This increases the risk of sensitive data being intercepted by unauthorized personnel, which can lead to possible data breaches or other security incidents. It is generally recommended to use more secure authentication methods such as tokens, hashes, or keys.

How to Fix

To address the issue, we need to create an OpenAPI specification that follows secure communication protocols and proper API key handling. Here's an example OpenAPI spec in YAML format that would comply with this policy:

1. Use of HTTPS: The servers section specifies a URL that begins with https://, ensuring that all data, including API keys, is encrypted in transit. This is crucial to prevent interception of sensitive data, including API keys, by unauthorized parties.
2. Security Schemes: In the components.securitySchemes, an API key security scheme is defined (ApiKeyAuth). This specifies that the API key should be included in the request header. The key is named X-API-KEY, indicating where and how the API key should be sent.
3. Secure Endpoints: Under paths, the /secureEndpoint path is defined to use the ApiKeyAuth security scheme, meaning that accessing this endpoint requires a valid API key. The security requirement at the operation level ensures that each request to this endpoint must include the API key in the header, as defined in the securitySchemes.

By adhering to these practices, the OpenAPI spec ensures secure communication (via HTTPS) and proper handling of API keys, thus complying with the ClearTestAPIKey Cortex Cloud AppSec rule. This rule checks for the use of insecure protocols (like HTTP or WS) and the improper handling of API keys, both of which are addressed in the provided spec. [source,go]

openapi: 3.0.0 info: title: Secure API version: 1.0.0

servers:

• url: https://api.example.com description: Secure server

components: securitySchemes: ApiKeyAuth: type: apiKey in: header name: X-API-KEY

paths: /secureEndpoint: get: summary: Secure endpoint requiring API key security: - ApiKeyAuth: [] responses: '200': description: Success