Skip to content

Add Security Considerations (3.0.4) #3894

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 11, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions versions/3.0.4.md
Original file line number Diff line number Diff line change
Expand Up @@ -3517,6 +3517,32 @@ Two examples of this:
1. The [Paths Object](#pathsObject) MAY be empty. It may be counterintuitive, but this may tell the viewer that they got to the right place, but can't access any documentation. They'd still have access to the [Info Object](#infoObject) which may contain additional information regarding authentication.
2. The [Path Item Object](#pathItemObject) MAY be empty. In this case, the viewer will be aware that the path exists, but will not be able to see any of its operations or parameters. This is different from hiding the path itself from the [Paths Object](#pathsObject), because the user will be aware of its existence. This allows the documentation provider to finely control what the viewer can see.

## Security Considerations
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an excellent PR.


### OpenAPI Document Formats

OpenAPI documents use JSON, YAML, and JSON Schema, and therefore share their security considerations:
- [JSON](https://www.iana.org/assignments/media-types/application/json)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [JSON](https://www.iana.org/assignments/media-types/application/json)
- [JSON](https://www.rfc-editor.org/rfc/rfc8259.html#section-12)

Why not directly reference the section on security considerations?

- [YAML](https://www.iana.org/assignments/media-types/application/yaml)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [YAML](https://www.iana.org/assignments/media-types/application/yaml)
- [YAML](https://www.rfc-editor.org/rfc/rfc9512#name-security-considerations)

- [JSON Schema Core](https://json-schema.org/draft/2020-12/json-schema-core#section-13)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [JSON Schema Core](https://json-schema.org/draft/2020-12/json-schema-core#section-13)
- [JSON Schema Core](https://json-schema.org/draft/2020-12/json-schema-core#name-security-considerations)

- [JSON Schema Validation](https://json-schema.org/draft/2020-12/json-schema-validation#name-security-considerations)

### Tooling and Usage Scenarios

In addition, OpenAPI documents are processed by a wide variety of tooling for numerous different purposes, such as client code generation, documentation generation, server side routing, and API testing. OpenAPI document authors must consider the risks of the scenarios where the OpenAPI document may be used.

### Security Schemes

An OpenAPI document describes the security schemes used to protect the resources it defines. The security schemes available offer varying degrees of protection. Factors such as the sensitivity of the data and the potential impact of a security breach should guide the selection of security schemes for the API resources. Some security schemes, such as basic auth and OAuth Implicit flow, are supported for compatibility with existing APIs. However, their inclusion in OpenAPI does not constitute an endorsement of their use, particularly for highly sensitive data or operations.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for including this. I think this opens the door for some other proposals to officially signal that some of the less secure schemes will be deprecated in future versions of the API. (similar to what OpenAPI does today to deprecate resources).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@miqui credit goes to @darrelmiller – he wrote this as a separate document (because we can't change the old specs) and I'm just putting it in the new versions of the spec :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @darrelmiller !


### Handling External Resources

OpenAPI documents may contain references to external resources that may be dereferenced automatically by consuming tools. External resources may be hosted on different domains that may be untrusted. References in an OpenAPI document, or across OpenAPI documents may cause a cycle. Tooling must detect and handle cycles to prevent resource exhaustion.

### Markdown and HTML Sanitization

Certain properties allow the use of Markdown which can contain HTML including script. It is the responsibility of tooling to appropriately sanitize the Markdown.

## <a name="revisionHistory"></a>Appendix A: Revision History

Version | Date | Notes
Expand Down