Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Protect your Umbraco site from MIME sniffing vulnerabilities using security headers like X-Content-Type-Options.
Checks that your site contains a header used to protect against Multipurpose Internet Mail Extensions (MIME) sniffing vulnerabilities.
This health check can be fixed by adding a header before the response is started.
Preferable you use a security library like NWebSec.
If you take a NuGet dependency on NWebsec.AspNetCore.Middleware/, you can use third extension methods on WebApplication
.
If you don't like to have a dependency on third party libraries. You can add the following custom middleware to the request pipeline.
First create the middleware class:
Next register it in Program.cs
This header is non-standard and should not be used.
For more information about the X-XSS-Protection header, and why it should not be used, see MDN web docs.
This health check can be fixed by ensuring no middleware adds the header.
Disable debug compilation mode in Umbraco to boost performance by updating JSON configuration.
Leaving debug compilation mode enabled can severely slow down a website and take up more memory on the server.
This health check can be fixed by providing configuration on the following path: Umbraco:CMS:Hosting:Debug
.
This configuration can be setup in a configuration source of your choice. This guide shows how to set it up in one of the JSON file sources.
The following JSON needs to be merged into one of your JSON sources. By default the following JSON sources are used: appSettings.json
and appSettings.<environment>.json
, e.g. appSettings.Development.json
or appSettings.Production.json
.
One example that can be used for production:
Learn how to protect your Umbraco site from clickjacking attacks using X-Frame-Options and security headers.
Checks if your site is allowed to be IFRAMEd by another site and thus would be susceptible to click-jacking.
This health check can be fixed by adding a header before the response is started.
Preferable you use a security library like NWebSec.
If you take a NuGet dependency on NWebsec.AspNetCore.Middleware/, you can use third extension methods on IApplicationBuilder
.
Avoid third-party library dependency by using custom middleware added to the request pipeline.
Checks to make sure macro errors are not set to throw a YSOD (yellow screen of death), which would prevent certain or all pages from loading completely.
Macros will be removed in the next version. Consider using Partial Views or Blocks in Rich Text Editor.
This health check can be fixed by providing configuration on the following path: Umbraco:CMS:Content:MacroErrors
.
This configuration can be setup in a configuration source of your choice. This guide shows how to set it up in one of the json file sources.
The following json needs to be merged into one of you json sources. By default the following json sources are used: appSettings.json
and appSettings.<environment>.json
, e.g. appSettings.Development.json
or appSettings.Production.json
.
One example that can be used in production, but is not recommended for development:
Checks that the web server folder and file permissions are set correctly for Umbraco to run.
This health check can be fixed by ensuring that the process running Umbraco also has write access to the listed folders and files.
Here's an example of how to adjust permissions for a folder. This process works the same way for files.
First we see an example of an error from the health check
To fix this, we find the specified folder, from the report and choose Properties
and the Security
tab.
From here you can edit the permissions for a specific user or user group.
For security reasons we recommend only giving write access to the required users or groups.
Check to make sure a fixed application URL is specified. This URL is for example used when sending emails from backoffice. If this is not specified in configuration, Umbraco gets the application URL from last host used to request the application
This health check can be fixed by providing configuration on the following path: Umbraco:CMS:WebRouting:UmbracoApplicationUrl
.
This configuration can be setup in a configuration source of your choice. This guide shows how to set it up in one of the JSON file sources.
The following JSON needs to be merged into one of your JSON sources. By default the following JSON sources are used: appSettings.json
and appSettings.<environment>.json
, e.g. appSettings.Development.json
or appSettings.Production.json
.
One example that can be used in production
If the site is hosted on Umbraco Cloud, changing the above configuration will have no effect. The site will always use the URL set in the`umbraco-cloud.json` file, which can not be changed.
Checks to see if your site reveals information in its headers that gives away unnecessary details about the technology used to build and host it.
This health check can be fixed by removing headers before the response is started.
Be aware these headers are often added by the server and not by the application.
Unless you publicly expose the Kestrel server (), you can't handle this directly in middleware.
For IIS you will need to manipulate web.config
(If you don't have web.config
already in your project you will need to add it at the root). Ensure to remove the custom X-Powered-By
and Server
header as shown in the following example.
The removeServerHeader
attribute is added in IIS 10.0 and does not work in versions of Windows prior to Windows Server version 1709 or Windows 10 version 1709.
By default Kestrel will only expose the Server
header. To disable this, you have to configure Kestrel in Program.cs
. You can use the UseKestrel
extension method on WebApplicationBuilder
like in the following example.
If notifications are used, the 'from' email address should be specified and changed from the default value.
This health check can be fixed by providing configuration on the following path: Umbraco:CMS:Content:Notifications:Email
.
This configuration can be setup in a configuration source of your choice. This guide shows how to set it up in one of the JSON file sources.
The following JSON needs to be merged into one of your JSON sources. By default the following JSON sources are used: appSettings.json
and appSettings.<environment>.json
, e.g. appSettings.Development.json
or appSettings.Production.json
.
One example that can be used:
Checks if your site is configured to work over HTTPS and if the Umbraco related configuration for that is correct.
This health check checks a couple of things.
First of all, it ensures that your website is running on HTTPS using a valid certificate.
Furthermore, it is used to specify the configuration on the following path: Umbraco:CMS:Global:UseHttps
.
This configuration can be setup in a configuration source of your choice. This guide shows how to set it up in one of the JSON file sources.
The following JSON needs to be merged into one of your JSON sources. By default the following JSON sources are used: appSettings.json
and appSettings.<environment>.json
, e.g. appSettings.Development.json
or appSettings.Production.json
.
One example that can be used:
Checks that valid settings for sending emails are in place.
This health check can be fixed by providing configuration on the following path: Umbraco:CMS:Global:Smtp
This configuration can be setup in a configuration source of your choice. This guide shows how to set it up in one of the JSON file sources.
The following JSON needs to be merged into one of your JSON sources. By default the following JSON sources are used: appSettings.json
and appSettings.<environment>.json
, e.g. appSettings.Development.json
or appSettings.Production.json
.
Learn about the health checks that check for cookie hijacking and protocol downgrade attacks protection.
Checks if your site, when running with HTTPS, contains the Strict-Transport-Security Header (HSTS).
This health check can be fixed by adding the Strict-Transport-Security
header to responses. The header tells browsers that future requests should be made over HTTPS only.
Enabling HSTS on a domain will cause browsers to only use HTTPS (not HTTP) to communicate with your site. Only enable HSTS on domains that can, and should, use HTTPS exclusively.
ASP.NET Core implements HSTS with the UseHsts
extension method.
You can add UseHsts
after the env.IsDevelopment()
check-in Program.cs
.
This example only enables HSTS if the app is not running in development mode. UseHsts
isn't recommended in development because the HSTS settings are highly cacheable by browsers.
An example that can be used on localhost, is if you have a local Simple Mail Transfer Protocol (SMTP) server running during development. This could be a tool like .
Full details of UseHsts
, and additional configuration, can be found in the .
Below is a list of guides for Health Checks in Umbraco.