12.0.0 Release Notes

[Marsup]

Summary

This major version contains a single breaking change, disabling by default the HTML escaping of error messages.

• Upgrade time: moderate to none
• Complexity: low
• Risk: moderate

⚠️ Breaking changes

Optional HTML escaping

Previously, joi escaped the parts of the error messages where an attacker could maliciously inject some HTML code to try and trick the receiver of the error message.

This was especially important as joi was mostly used in an hapi context, and making hapi a vector of attack was not an option.

Now joi is being used in more contexts where people only want plain text, or already have strategies to protect themselves against such an attack, so it makes sense to make it optional by default, with an option (escapeHtml) to get the old behavior for those who want it.

The migration depends on whether or not you want to keep the old security feature and on which platform you use joi on :

• Standalone should not be affected by this as you probably expect plain text.
• Servers are not directly impacted by this change as they are a mere vector for this attack, but you should carefully evaluate whether your client code is protected against those.
• Browsers always saw HTML entities anyway, so I don't expect an impact there. But the recent difficulty to bundle joi with webpack should be alleviated by this.

✨ New features

None.

👥 Contributors

The contributors to this release are : myself.

[hueniverse]

The main attack vector is echoing back content from the browser. If an attacker can cause a browser to send a request to a joi-enabled server, the server will run the joi validation and then send back the error message. If the error message contains data received from the browser (e.g. an invalid string that doesn't meet the server requirements), that data can be used to produce a response that then executes code on the browser. However, because the response came from the server, XSS protection will not work and the code will execute as if it came from the server, including access to credentials and other confidential data.

Even just telling the client which fields were invalid without the values can be exploited if your joi rules allow for any unknown keys.

So -

The issue here is if you ever send back validation errors to the client, and these errors include the invalid data that failed validation, then you can be creating an attack vector. The previous approach was to just escape everything, taking the most aggressive and conservative approach. Another is to never send back an explanation by default.

I am undecided as to how I want to handle this in hapi, but if you move to this new version, make sure to fully understand the impact this change can have on your application security.

[spanditcaa]

@hueniverse we have had a plugin running since we adopted hapi that suppressed the Joi error and returned a generic message if in 'production'. The detailed errors are useful to developers against our APIs but we didn't want to reveal them in prod.

[sholladay]

I'm trying to understand why escapeHtml defaults to false. I get the reasoning behind it being optional and why some people would maybe want it to be false. But surely joi's primary use case is still hapi servers. No?

It is especially confusing when the README specifically states:

Joi doesn't directly support browsers ...

[Marsup]

Joi is very often used as standalone as well.

My take on this is that this is a non-issue, most of the industry moved on to solid UI frameworks that usually take care of that escaping for you, so the chances of security issues are, I think, very low if not nil. If you are not, then you would need to assess the security of your solution anyway if you are serious about reinventing your own wheel.