HTTP signature

Levels of estimated error severity.

If an error is present in the context of an API (or endpoint), it applies only to that API (or endpoint).

CRITICAL	This severity level implies that the process always/usually works badly.
MAJOR	This severity level implies that the process works badly in some cases.
MEDIUM	This flaw results in unfavorable behavior but the system remains functioning.
LOW	This type of flaw won’t cause any major breakdown in the system.

List of identified issues in this category (click on the title to show details)

HTTP-001: Invalid format of Date or Original-Date headers

Description	A typical problem is using wrong timezone. The specification says: "The format of the Original-Date header, if included, MUST match the "regular" format of the Date header, as defined in RFC 2616." and the RFC says: "All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception.".
Estimated severity	CRITICAL
Examples	A valid value: Sat, 01 Jul 2023 02:06:08 GMT Invalid values: Sat, 03 Jun 2023 04:08:54 CEST Thu, 22 Dec 2022 10:49:01 GMT+2:00
Suggested action	Enforce absolute compliance with the specification
How communicated	Monitoring system Problem occurred for at least 4 providers in the DEV network

HTTP-002: Wrong time in Date or Original-Date headers – server clock not synchronized

Description	The specification says: "(...) you MUST make sure that your clock is synchronized (otherwise your clients won't be able to use your service)."
Estimated severity	CRITICAL
Examples
Suggested action	Synchronize clocks
How communicated	Monitoring system Problem occurred for at least 3 providers in DEV (link1, link2)

HTTP-003: Invalid value in Digest header

Description	Possible issue might be that the digest is calculated before the content is fully encoded. The specification says: "Many frameworks or proxies might try to automatically modify your response after you sign it. For example, they may try to add additional gzip coding to your response's Content-Encodings if they detect that the client supports it. In many cases, this would be a good thing, but in this case, such changes could break your HTTP Signature (because we sign the content after it has been encoded). Make sure that you disable such automatic modifications when you use HTTP Signatures for signing."
Estimated severity	CRITICAL
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Monitoring system Problem occurred for at least 2 providers in PROD and probably for 11 providers in DEV (link1, link2)

HTTP-004: Rejecting valid keyId parameter

Description	The client/server might be using the wrong registry, i.e. PROD instead of DEV, or vice versa
Estimated severity	CRITICAL
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Problem occurred for at least 5 providers in PROD (link1, link2) and for app. 3 providers in DEV (link1, link2)

HTTP-005: Invalid signature

Description	It may be a problem with proxies replacing the Date header, thus invalidating the signature. The specification says: "If your proxy is replacing the Date header, and you cannot reliably reconfigure it to not do so, then you MAY use the Original-Date header as a replacement for the Date header."
Estimated severity	CRITICAL
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	Problem occurred for at least 5 providers in PROD (link1, link2) and for app. 3 providers in DEV (link1, link2)

HTTP-006: Not signing Accept-Signature header

Description	The client indicates whether it wants the server to sign the response by sending the Accept-Signature header. However, the header itself must be signed, because otherwise the server has to ignore it. The specification says: "Servers MUST ignore all request headers which hadn't been signed by the client."
Estimated severity	CRITICAL
Examples
Suggested action	Enforce absolute compliance with the specification
How communicated	From the experience of UW (app. 5 partners)