Secure Sitecore : Why use a custom 500 error page?
Secure Sitecore : Why use a custom 500 error page?
Enable custom errors to restrict users from seeing sensitive information such as the paths, stack trace and .NET version information. A potential hacker can get a lot of information on your environment just by looking at the default error page.
There are several things you could do to secure your Sitecore instance, namely the Sitecore Security Hardening Guide. Along with the documented steps, there are several others you should implement to secure your instances.
[caption id="attachment_237" align="aligncenter" width="900"]
[/caption]
The good thing is that Sitecore by default sets the customErrors to RemoteOnly. This way it shows you the information when you are working locally and will display generic information when accessing the site remotely.
[caption id="attachment_238" align="aligncenter" width="900"]
[/caption]
Most of us are used to setting up a default 500 and 404 pages but I have seen in some instances that developers forget. The best thing to do is to set the default 500 page. For now I am going to set it to a physical Html file. There are different schools of thought depending on the security team you need to answer to. The ones I have had to deal with argue that if you set it to a Sitecore page /500 for instance, it might cause a recurring loop if Sitecore solution code itself is an issue. Instead if you use a standalone 500.html file, it will render always. The disadvantage is that we are unable to manage content on this file without code change.
[caption id="attachment_242" align="aligncenter" width="900"]
[/caption]
This is better but we can do better. By default the redirectMode is ResponseRedirect and it places the path in the url. To overcome that we add in the redirectMode as ResponseRewrite so that the url where the error occurred stays as is but the response will be shown from the custom error page.
[caption id="attachment_245" align="aligncenter" width="900"]
[/caption]
https://xchangesitecore.com/secure-sitecore-why-use-a-custom-500-error-page/ Vikash Raaj
There are several things you could do to secure your Sitecore instance, namely the Sitecore Security Hardening Guide. Along with the documented steps, there are several others you should implement to secure your instances.
[caption id="attachment_237" align="aligncenter" width="900"]
[/caption]The good thing is that Sitecore by default sets the customErrors to RemoteOnly. This way it shows you the information when you are working locally and will display generic information when accessing the site remotely.
[caption id="attachment_238" align="aligncenter" width="900"]
[/caption]Most of us are used to setting up a default 500 and 404 pages but I have seen in some instances that developers forget. The best thing to do is to set the default 500 page. For now I am going to set it to a physical Html file. There are different schools of thought depending on the security team you need to answer to. The ones I have had to deal with argue that if you set it to a Sitecore page /500 for instance, it might cause a recurring loop if Sitecore solution code itself is an issue. Instead if you use a standalone 500.html file, it will render always. The disadvantage is that we are unable to manage content on this file without code change.
1 | <customErrors mode="On" defaultRedirect="~/Error/500.html" /> |
[caption id="attachment_242" align="aligncenter" width="900"]
[/caption]This is better but we can do better. By default the redirectMode is ResponseRedirect and it places the path in the url. To overcome that we add in the redirectMode as ResponseRewrite so that the url where the error occurred stays as is but the response will be shown from the custom error page.
1 2 | <customErrors mode="On" defaultRedirect="~/Error/500.html" redirectMode="ResponseRewrite" /> |
[caption id="attachment_245" align="aligncenter" width="900"]
[/caption]https://xchangesitecore.com/secure-sitecore-why-use-a-custom-500-error-page/ Vikash Raaj
Comments
Post a Comment