From 6b5e85e7d6b13007d8bd88d43bd130bc887f501d Mon Sep 17 00:00:00 2001 From: rahariya Date: Fri, 31 Jul 2020 15:23:39 +1000 Subject: [PATCH 1/4] Update api-security.md Updated the descriptions for using API Keys and Authorization header. --- sections/api-security.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sections/api-security.md b/sections/api-security.md index 4b75724..4b50854 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -31,12 +31,12 @@ 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. - 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. - 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. From 1648f2243364a03e08c028a451214bcd335338f6 Mon Sep 17 00:00:00 2001 From: rahariya Date: Fri, 31 Jul 2020 15:48:06 +1000 Subject: [PATCH 2/4] Corrected grammatical mistakes Updated the CORS header sentence (dot point 9), under Authentication and Authorization. This commit aims to resolve https://github.com/apigovau/national-api-design-standards/issues/10 --- sections/api-security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sections/api-security.md b/sections/api-security.md index 4b50854..40a4d29 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -38,7 +38,7 @@ Depending on the security classification you may be required to establish the fo - 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 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 From 0d409ba8f5cfd0832b1788263c6c44f5c73582d1 Mon Sep 17 00:00:00 2001 From: Peeyush RAHARIYA Date: Fri, 31 Jul 2020 16:06:29 +1000 Subject: [PATCH 3/4] clean as original national api standards master branch --- .gitignore | 1 + sections/api-security.md | 8 ++++---- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/.gitignore b/.gitignore index 3ee5d6f..2c2e08a 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,4 @@ node_modules target node_modules +/.vs/slnx.sqlite diff --git a/sections/api-security.md b/sections/api-security.md index 40a4d29..4c6d290 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -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. Authorization tokens identify a user — the person — that is using the app or site. +- The `Authorization: Bearer` header **MUST** be used for authentication/authorization e.g. using a JWT token. - 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 identify the calling project — the application or site — making the call to an API. +- 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 **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 reduces the overall security mechanisms built into web browsers by selectively relaxing cross-origin restrictions. +- CORS headers should only be used when necessary as it reduce 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 @@ -128,4 +128,4 @@ It is preferable to use the security policy features available in the WoG API Ga | OAUTH | Filter -\> OAUTH | OAUTH can be used for authorizing the consumers | Optional as it depends on business requirements | | CORS | Listeners-\>Path | CORS can be restricted at path level | Recommended | -The WoG API Team can provide advice on which API Gateway security policies should be applied. +The WoG API Team can provide advice on which API Gateway security policies should be applied. \ No newline at end of file From 0f09eccaab715aa39a74ecb68746e72a6006e501 Mon Sep 17 00:00:00 2001 From: Peeyush RAHARIYA Date: Fri, 7 Aug 2020 14:24:13 +1000 Subject: [PATCH 4/4] Corrected Second sentence in API security section --- sections/api-security.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sections/api-security.md b/sections/api-security.md index 4c6d290..2653db2 100644 --- a/sections/api-security.md +++ b/sections/api-security.md @@ -5,7 +5,7 @@ ______________________________________________________________________________ Applying the right level of security will allow your APIs to perform well without compromising on the security risk. -To secure your APIs the security standards are grouped into three categories: Design, Transport, and Authentication and Authorisation. +To secure your APIs the security standards are grouped into three categories: Design, Transport, and Authentication & Authorisation. At minimum the security standards that are defined here **MUST** be applied. Further security considerations may apply depending on the API design and requirements – refer to our [API Design Considerations section](getting-started.html#how-to-apply-the-design-standard) for more details.