Skip to content
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

Update api-security.md #35

Merged
merged 2 commits into from
Mar 19, 2021
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
6 changes: 3 additions & 3 deletions sections/api-security.md
Original file line number Diff line number Diff line change
Expand Up @@ -31,14 +31,14 @@ Depending on the security classification you may be required to establish the fo
## Authentication and Authorization

- Basic or Digest authentication **SHOULD NOT** be used.
- The `Authorization: Bearer` header **MUST** be used for authentication/authorization e.g. using a JWT token.
- The `Authorization: Bearer` header **MUST** be used for authentication/authorization e.g. using a JWT token. Authorization tokens identify a user — the person — that is using the app or site.
Copy link

Choose a reason for hiding this comment

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

Not every token needs to represent a person, e.g. Client credential flow.
No need for the additional text

- A refresh token **SHOULD** be provided for extending expiry time of existing token without having to provide the credentials again.
- Always set a reasonable expiration date for tokens. JWT token lifetime **SHOULD NOT*** exceed 5 minutes.
- JWT refresh tokens **SHOULD** be used when new JWT tokens are required outside of this lifetime.
- All APIs **MUST** have a policy that only allows access based on a valid API key.
- API keys **MUST** be used for client authentication. Use of API keys should only be permitted when TLS is enabled. Rotation policy for API Key should be implemented as well.
- API keys **MUST** be used for client authentication. Use of API keys should only be permitted when TLS is enabled. Rotation policy for API Key should be implemented as well. API keys identify the calling project — the application or site — making the call to an API.
- API keys **SHOULD NOT** be included in the URL or query string. API keys **SHOULD** be included in the HTTP header as query strings may be saved by the client or server in unencrypted format by the browser or server application.
- CORS headers should only be used when necessary as it reduce overall security mechanisms built into web browsers by selectively relaxing cross-origin restrictions.
- CORS headers should only be used when necessary as it reduces the overall security mechanisms built into web browsers by selectively relaxing cross-origin restrictions.
- A request from Domain A is considered cross-origin when it tries to make a request to an API that is hosted in Domain B.
- For security reasons, browsers restrict cross-origin HTTP requests.
- The Cross-Origin Resource Sharing standard works by adding new HTTP headers (i.e. Access-Control-Allow-Origin) that allow servers to describe the set of origins that are permitted to access the API
Expand Down