Skip to content

Commit ec1f79a

Browse files
biazmoreirabiazmoreira
committed
Update JSON limits Docs for Vault
1 parent 401cfbb commit ec1f79a

File tree

12 files changed

+156
-144
lines changed

12 files changed

+156
-144
lines changed

‎content/vault/global/partials/important-changes/summary-tables/1_16.mdx‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,7 @@ Introduced | Recommendations | Edition | Change
1919
1.16.0 | **Yes** | All | [Secrets Sync cannot be activated from chroot namespace](/vault/docs/v1.16.x/updates/important-changes#secrets-sync-cannot-be-activated-from-chroot-namespace)
2020
1.16.0 | No | Enterprise | [Secrets Sync now requires setting a one-time flag before use](/vault/docs/v1.16.x/updates/important-changes#secrets-sync-now-requires-setting-a-one-time-flag-before-use)
2121
1.16.18 | No | All | [Strict validation for Azure auth login requests](/vault/docs/v1.16.x/updates/important-changes#strict-azure)
22+
1.16.25 | No | All | [JSON Payload Limits](/vault/docs/v1.16.x/updates/important-changes#json-limits)
2223

2324

2425
### Known issues

‎content/vault/global/partials/important-changes/summary-tables/1_18.mdx‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,7 @@ Introduced | Recommendations | Edition | Change
1919
1.18.0 | **Yes** | All | [Docker image no longer contains curl](/vault/docs/v1.18.x/updates/important-changes#docker-image-no-longer-contains-curl)
2020
1.18.2 | **Yes** | All | [Anonymous product usage metrics collection](/vault/docs/v1.18.x/updates/important-changes#product-usage-reporting)
2121
1.18.7 | No | All | [Strict validation for Azure auth login requests](/vault/docs/v1.18.x/updates/important-changes#azure-auth-plugin-requires-resource_group_name-vm_name-and-vmss_name-to-match-the-jwt-claims-on-login)
22+
1.18.14 | No | All | [JSON Payload Limits](/vault/docs/v1.18.x/updates/important-changes#json-limits)
2223

2324

2425
### Known issues

‎content/vault/global/partials/important-changes/summary-tables/1_19.mdx‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -22,6 +22,7 @@ Introduced | Recommendations | Edition | Change
2222
1.19.0 | No | All | [RADIUS authentication is no longer case sensitive](/vault/docs/v1.19.x/updates/important-changes#case-sensitive)
2323
1.19.0 | No | All | [Transit support for Ed25519ph and Ed25519ctx signatures](/vault/docs/v1.19.x/updates/important-changes#ed25519)
2424
1.19.1 | **Yes** | All | [Strict validation for Azure auth login requests](/vault/docs/v1.19.x/updates/important-changes#strict-azure)
25+
1.19.9 | No | All | [JSON Payload Limits](/vault/docs/v1.19.x/updates/important-changes#json-limits)
2526

2627

2728
### Known issues

‎content/vault/global/partials/important-changes/summary-tables/1_20.mdx‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -14,6 +14,8 @@ Introduced | Recommendations | Edition | Change
1414
---------- | --------------- | ---------- | ------
1515
1.20.0 | **Yes** | All | [Key pair authentication for Snowflake DB secrets engine](/vault/docs/v1.20.x/updates/important-changes#snowflake-keypair-auth)
1616
1.20.0 | **Yes** | All | [Audience warning for Kubernetes authentication roles](#k8-audience-warning)
17+
1.20.3 | No | All | [JSON Payload Limits](/vault/docs/v1.20.x/updates/important-changes#json-limits)
18+
1719

1820

1921
### Known issues

‎content/vault/v1.16.x/content/api-docs/index.mdx‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -316,4 +316,19 @@ A maximum request size of 32MB is imposed to prevent a denial of service attack
316316
with arbitrarily large requests; this can be tuned per `listener` block in
317317
Vault's server configuration file.
318318
319+
Vault also supports several listener options to enforce payload size limits for to incoming JSON
320+
request bodies.
321+
322+
You can configure the payload limits individullly on each listener and give
323+
administrators granular control over the:
324+
325+
- maximum allowed nesting depth of a JSON object or array (`max_json_depth`).
326+
- maximum allowed length for any single string value in the payload (`max_json_string_value_length`.)
327+
- maximum number of key-value pairs allowed in a single JSON object (`max_json_object_entry_count`).
328+
- maximum number of elements permitted in a single JSON array `max_json_array_element_count`.
329+
330+
The configuration defaults provide intentionally generous limits to accommodate
331+
a wide range of legitimate use cases while still guarding against most malicious
332+
or malformed requests.
333+
319334
[proxy]: /vault/docs/agent-and-proxy/proxy#listener-stanza

‎content/vault/v1.18.x/content/api-docs/index.mdx‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -340,4 +340,19 @@ A maximum request size of 32MB is imposed to prevent a denial of service attack
340340
with arbitrarily large requests; this can be tuned per `listener` block in
341341
Vault's server configuration file.
342342
343+
Vault also supports several listener options to enforce payload size limits for to incoming JSON
344+
request bodies.
345+
346+
You can configure the payload limits individullly on each listener and give
347+
administrators granular control over the:
348+
349+
- maximum allowed nesting depth of a JSON object or array (`max_json_depth`).
350+
- maximum allowed length for any single string value in the payload (`max_json_string_value_length`.)
351+
- maximum number of key-value pairs allowed in a single JSON object (`max_json_object_entry_count`).
352+
- maximum number of elements permitted in a single JSON array `max_json_array_element_count`.
353+
354+
The configuration defaults provide intentionally generous limits to accommodate
355+
a wide range of legitimate use cases while still guarding against most malicious
356+
or malformed requests.
357+
343358
[proxy]: /vault/docs/agent-and-proxy/proxy#listener-stanza

‎content/vault/v1.18.x/content/docs/upgrading/upgrade-to-1.16.x.mdx‎

Lines changed: 23 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -2,8 +2,8 @@
22
layout: docs
33
page_title: Upgrade to Vault 1.16.x - Guides
44
description: |-
5-
Deprecations, important or breaking changes, and remediation recommendations
6-
for anyone upgrading to 1.16.x from Vault 1.15.x.
5+
Deprecations, important or breaking changes, and remediation recommendations
6+
for anyone upgrading to 1.16.x from Vault 1.15.x.
77
---
88

99
# Overview
@@ -18,13 +18,13 @@ Vault 1.15. **Please read carefully**.
1818

1919
## Important changes
2020

21-
### JSON payload limits (##json-payload-limits)
21+
### JSON Payload Limits ((#json-limits))
2222

23-
| Change | Affected version | Vault edition
24-
| ------------ | ---------------- | -------------
25-
| New behavior | 1.16.25 | All
26-
| | | |
27-
| | | |
23+
| Change | Affected version | Vault edition |
24+
|--------------|----------------------------------|---------------|
25+
| New behavior | 1.16.25, 1.18.14, 1.19.9, 1.20.3 | All |
26+
| | | |
27+
| | | |
2828

2929
To guard against potential Denial-of-Service (DoS) attacks, Vault now supports
3030
several listener options to enforce payload size limits for to incoming JSON
@@ -79,9 +79,9 @@ more details on plugin environment variables.
7979

8080
<Highlight title="Avoid conflicts with containerized plugins">
8181

82-
Containerized plugins do not inherit system-defined environment variables. As
83-
a result, containerized plugins cannot have conflicts with Vault environment
84-
variables.
82+
Containerized plugins do not inherit system-defined environment variables. As
83+
a result, containerized plugins cannot have conflicts with Vault environment
84+
variables.
8585

8686
</Highlight>
8787

@@ -98,10 +98,10 @@ $ export VAULT_PLUGIN_USE_LEGACY_ENV_LAYERING=true
9898
Setting `VAULT_PLUGIN_USE_LEGACY_ENV_LAYERING` to `true` tells Vault to:
9999

100100
1. prioritize environment variables from the Vault server environment whenever
101-
the system detects a variable conflict.
101+
the system detects a variable conflict.
102102
1. report on plugin variable conflicts during the unseal process by printing
103-
warnings for plugins with conflicting environment variables or logging an
104-
informational entry when there are no conflicts.
103+
warnings for plugins with conflicting environment variables or logging an
104+
informational entry when there are no conflicts.
105105

106106
For example, assume you set `VAULT_PLUGIN_USE_LEGACY_ENV_LAYERING` to `true`
107107
and have an environment variable `SOURCE=parent`.
@@ -161,14 +161,14 @@ endpoint, will result in the following warning from Vault:
161161

162162
<CodeBlockConfig hideClipboard>
163163

164-
```shell-session
164+
```shell-session
165165
166-
WARNING! The following warnings were returned from Vault:
166+
WARNING! The following warnings were returned from Vault:
167167
168-
* default_report_months is deprecated: defaulting to billing start time
168+
* default_report_months is deprecated: defaulting to billing start time
169169
170170
171-
```
171+
```
172172

173173
</CodeBlockConfig>
174174

@@ -180,14 +180,15 @@ Attempts to set `current_billing_period` will result in the following warning fr
180180

181181
<CodeBlockConfig hideClipboard>
182182

183-
```shell-session
183+
```shell-session
184184
185-
WARNING! The following warnings were returned from Vault:
185+
WARNING! The following warnings were returned from Vault:
186186
187-
* current_billing_period is deprecated; unless otherwise specified, all requests will default to the current billing period
187+
* current_billing_period is deprecated; unless otherwise specified, all requests will default to the current billing
188+
period
188189
189190
190-
```
191+
```
191192

192193
</CodeBlockConfig>
193194

‎content/vault/v1.18.x/content/docs/upgrading/upgrade-to-1.18.x.mdx‎

Lines changed: 23 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -18,47 +18,29 @@ Vault 1.17. **Please read carefully**.
1818

1919
## Important changes
2020

21-
### JSON Payload Limits
22-
23-
| Change | Affected version | Vault edition
24-
| ------------ | ---------------- | -------------
25-
| New behavior | 1.18.14 | All
26-
| | | |
27-
| | | |
28-
29-
To provide deeper protection against potential Denial-of-Service (DoS) attacks, this release
30-
introduces several new security limits that are applied to incoming JSON request bodies.
31-
These settings are configured on a listener and give administrators granular control over the
32-
structure and size of JSON payloads that Vault will process.
33-
We've chosen defaults that are intentionally generous to accommodate a wide range of
34-
legitimate use cases, but they provide a strong defense against malicious or malformed requests.
35-
36-
`max_json_depth`
37-
This parameter specifies the maximum allowed nesting depth of a JSON object or array.
38-
It serves as a critical defense against "JSON depth bomb" attacks, where a malicious
39-
client sends a deeply nested payload to cause a stack overflow on the server.
40-
The default value is 500, which is well above the nesting level of any typical
41-
Vault configuration or secret, providing a robust safeguard without impacting normal operations.
42-
43-
`max_json_string_value_length`
44-
This parameter defines the maximum allowed length for any single string value
45-
within a JSON payload, measured in bytes. This limit prevents a client from
46-
sending a request with an extremely large string to cause excessive memory allocation on the server.
47-
The default value is 1,048,576 bytes (1MB), which is aligned with Vault's default storage backend
48-
limit and is large enough to comfortably accommodate common secrets like full TLS certificate chains.
49-
50-
`max_json_object_entry_count`
51-
This parameter sets the maximum number of key-value pairs allowed in a single JSON object.
52-
This is a direct defense against HashDoS (Hash Flooding) attacks, where an attacker could send
53-
an object with an enormous number of keys to overwhelm the server's CPU. A legitimate JSON object
54-
with more than 10,000 keys is extremely rare, so the default provides a high ceiling for normal operations
55-
while ensuring server stability.
56-
57-
`max_json_array_element_count`
58-
This parameter determines the maximum number of elements permitted in a single JSON array.
59-
Its primary purpose is to protect the server from having to construct and hold a massive,
60-
memory-intensive array in a single API response, which is most common during LIST operations on secrets paths.
61-
The default of 10,000 elements acts as a sensible guardrail.
21+
### JSON Payload Limits ((#json-limits))
22+
23+
| Change | Affected version | Vault edition |
24+
|--------------|----------------------------------|---------------|
25+
| New behavior | 1.16.25, 1.18.14, 1.19.9, 1.20.3 | All |
26+
| | | |
27+
| | | |
28+
29+
To guard against potential Denial-of-Service (DoS) attacks, Vault now supports
30+
several listener options to enforce payload size limits for to incoming JSON
31+
request bodies.
32+
33+
You can configure the payload limits individullly on each listener and give
34+
administrators granular control over the:
35+
36+
- maximum allowed nesting depth of a JSON object or array (`max_json_depth`).
37+
- maximum allowed length for any single string value in the payload (`max_json_string_value_length`.)
38+
- maximum number of key-value pairs allowed in a single JSON object (`max_json_object_entry_count`).
39+
- maximum number of elements permitted in a single JSON array `max_json_array_element_count`.
40+
41+
The configuration defaults provide intentionally generous limits to accommodate
42+
a wide range of legitimate use cases while still guarding against most malicious
43+
or malformed requests.
6244

6345
### Rekey cancellations use a nonce ((#rekey-cancel-nonce))
6446
| Change | Affected version | Affected deployments

‎content/vault/v1.19.x/content/api-docs/index.mdx‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -340,4 +340,19 @@ A maximum request size of 32MB is imposed to prevent a denial of service attack
340340
with arbitrarily large requests; this can be tuned per `listener` block in
341341
Vault's server configuration file.
342342
343+
Vault also supports several listener options to enforce payload size limits for to incoming JSON
344+
request bodies.
345+
346+
You can configure the payload limits individullly on each listener and give
347+
administrators granular control over the:
348+
349+
- maximum allowed nesting depth of a JSON object or array (`max_json_depth`).
350+
- maximum allowed length for any single string value in the payload (`max_json_string_value_length`.)
351+
- maximum number of key-value pairs allowed in a single JSON object (`max_json_object_entry_count`).
352+
- maximum number of elements permitted in a single JSON array `max_json_array_element_count`.
353+
354+
The configuration defaults provide intentionally generous limits to accommodate
355+
a wide range of legitimate use cases while still guarding against most malicious
356+
or malformed requests.
357+
343358
[proxy]: /vault/docs/agent-and-proxy/proxy#listener-stanza

‎content/vault/v1.19.x/content/docs/updates/important-changes.mdx‎

Lines changed: 23 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -22,47 +22,29 @@ before upgrading Vault.
2222

2323
## New behavior
2424

25-
### JSON Payload Limits
26-
27-
| Change | Affected version | Vault edition
28-
| ------------ | ---------------- | -------------
29-
| New behavior | 1.19.9 | All
30-
| | | |
31-
| | | |
32-
33-
To provide deeper protection against potential Denial-of-Service (DoS) attacks, this release
34-
introduces several new security limits that are applied to incoming JSON request bodies.
35-
These settings are configured on a listener and give administrators granular control over the
36-
structure and size of JSON payloads that Vault will process.
37-
We've chosen defaults that are intentionally generous to accommodate a wide range of
38-
legitimate use cases, but they provide a strong defense against malicious or malformed requests.
39-
40-
`max_json_depth`
41-
This parameter specifies the maximum allowed nesting depth of a JSON object or array.
42-
It serves as a critical defense against "JSON depth bomb" attacks, where a malicious
43-
client sends a deeply nested payload to cause a stack overflow on the server.
44-
The default value is 500, which is well above the nesting level of any typical
45-
Vault configuration or secret, providing a robust safeguard without impacting normal operations.
46-
47-
`max_json_string_value_length`
48-
This parameter defines the maximum allowed length for any single string value
49-
within a JSON payload, measured in bytes. This limit prevents a client from
50-
sending a request with an extremely large string to cause excessive memory allocation on the server.
51-
The default value is 1,048,576 bytes (1MB), which is aligned with Vault's default storage backend
52-
limit and is large enough to comfortably accommodate common secrets like full TLS certificate chains.
53-
54-
`max_json_object_entry_count`
55-
This parameter sets the maximum number of key-value pairs allowed in a single JSON object.
56-
This is a direct defense against HashDoS (Hash Flooding) attacks, where an attacker could send
57-
an object with an enormous number of keys to overwhelm the server's CPU. A legitimate JSON object
58-
with more than 10,000 keys is extremely rare, so the default provides a high ceiling for normal operations
59-
while ensuring server stability.
60-
61-
`max_json_array_element_count`
62-
This parameter determines the maximum number of elements permitted in a single JSON array.
63-
Its primary purpose is to protect the server from having to construct and hold a massive,
64-
memory-intensive array in a single API response, which is most common during LIST operations on secrets paths.
65-
The default of 10,000 elements acts as a sensible guardrail.
25+
### JSON Payload Limits ((#json-limits))
26+
27+
| Change | Affected version | Vault edition |
28+
|--------------|----------------------------------|---------------|
29+
| New behavior | 1.16.25, 1.18.14, 1.19.9, 1.20.3 | All |
30+
| | | |
31+
| | | |
32+
33+
To guard against potential Denial-of-Service (DoS) attacks, Vault now supports
34+
several listener options to enforce payload size limits for to incoming JSON
35+
request bodies.
36+
37+
You can configure the payload limits individullly on each listener and give
38+
administrators granular control over the:
39+
40+
- maximum allowed nesting depth of a JSON object or array (`max_json_depth`).
41+
- maximum allowed length for any single string value in the payload (`max_json_string_value_length`.)
42+
- maximum number of key-value pairs allowed in a single JSON object (`max_json_object_entry_count`).
43+
- maximum number of elements permitted in a single JSON array `max_json_array_element_count`.
44+
45+
The configuration defaults provide intentionally generous limits to accommodate
46+
a wide range of legitimate use cases while still guarding against most malicious
47+
or malformed requests.
6648

6749
### Transit support for Ed25519ph and Ed25519ctx signatures ((#ed25519))
6850

0 commit comments

Comments
 (0)