-Directly writing exceptions to a webpage without sanitization allows for a cross-site scripting -vulnerability if the value of the exception can be influenced by a user. +Directly writing error messages to a webpage without sanitization allows for a cross-site scripting +vulnerability if parts of the error message can be influenced by a user.
+This second example shows an input being validated using the JSON schema validator ajv
,
+and in case of an error, the error message is sent directly back in the response.
+
+This is unsafe, because the error message can contain parts of the input.
+For example, the input {'<img src=x onerror=alert(1)>': 'foo'}
will generate the error
+data/<img src=x onerror=alert(1)> should be number
, causing reflected XSS.
+
+ Processing user-controlled data with a method that allocates excessive amounts + of memory can lead to denial of service. +
+ +
+ If the JSON schema validation library ajv
is configured with
+ allErrors: true
there is no limit to how many error objects
+ will be allocated. An attacker can exploit this by sending an object that
+ deliberately contains a huge number of errors, and in some cases, with
+ longer and longer error messages. This can cause the service to become
+ unresponsive due to the slow error-checking process.
+
+ Do not use allErrors: true
in production.
+
+ In the example below, the user-submitted object req.body
is
+ validated using ajv
and allErrors: true
:
+
+ Although this ensures that req.body
conforms to the schema,
+ the validation itself could be vulnerable to a denial-of-service attack.
+ An attacker could send an object containing so many errors that the server
+ runs out of memory.
+
+ A solution is to not pass in allErrors: true
, which means
+ ajv
will only report the first error, not all of them:
+