> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/appsec-rules/iac-security/iam/appsec-openapi-13.md).

# 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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cortex-docs.paloaltonetworks.com/appsec-rules/iac-security/iam/appsec-openapi-13.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.