---
title: Designing secure error messages
---

> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).

When designing error messages, you should always consider the level of information revealed to the user. If you reveal too much information, the user may be overwhelmed and confused. Moreover, malicious users may exploit this information to gain detailed understanding of the system.

On the other hand, if you do not provide enough information for the user to understand the problem, seeing such error messages may be very frustrating for the user.

Information you should NOT include in the error messages:

- Stack trace
- Debug information

Information you should include in the error messages:

- What is the problem (generic description)
- What can the user do to fix the problem (suggestions)
- What can the user do to prevent this problem in the future

### Wrong

![Wrong - displaying debug information in error messages.](https://docs.kentico.com/docsassets/13/designing-secure-error-messages/Error_wrong.png "Wrong - displaying debug information in error messages.")

### Correct

![Correct - debug and stack trace information are not included in the error message, but the user learns the cause of the error.](https://docs.kentico.com/docsassets/13/designing-secure-error-messages/Error_correct.png "Correct - debug and stack trace information are not included in the error message, but the user learns the cause of the error.")

> **Note:** **Handled and unhandled errors**
>
> The error pages should be **consistent** throughout the whole system. Configuring different error pages for handled errors and unhandled errors (a page redirected by ASP.NET using the __ web.config key) can be a severe security risk. You should have only one error page for both of these cases.
>
> For more information, see [Handling 404 errors](https://docs.kentico.com/13/securing-websites/developing-secure-websites/handling-error-messages-securely/handling-404-errors.md).

## Time based errors

The time needed for processing a page after encountering an error can be considerably different from the processing time in other cases. The attackers can use this difference to guess if their input has caused any problems in the system.

There is no general recommendation on how to solve this problem. However, you can try to provide some malicious input yourself and observe how much time it takes the system to complete the request. This way, you can learn about potential weaknesses in the system.

## Storing the debug and trace information in the event log

Instead of showing detailed information about the problem in the error message, store the debug data and stack trace into the system's [Event log](https://docs.kentico.com/13/developing-websites/troubleshooting-websites/working-with-the-system-event-log.md) (where it can be viewed safely by administrators).

The following code example logs an event in the event log:

```csharp

using System;

using CMS.Core;

private void LogEvent(Exception ex)
{
    // Logs an error type event
    Service.Resolve<IEventLogService>().LogException("API Example", "APIEXAMPLE", ex, additionalMessage: "An error occurred. Message: " + ex.Message + ", StackTrace:" + ex.StackTrace);
}

```

## Configuring the error messages

To configure the system to display custom error messages, modify the web.config file, as described in [Handling 404 errors](https://docs.kentico.com/13/securing-websites/developing-secure-websites/handling-error-messages-securely/handling-404-errors.md).

## Disabling debugging

To disable debugging before going live, see [Web.config security settings](https://docs.kentico.com/13/securing-websites/deploying-websites-to-a-secure-environment/web-config-security-settings.md#error-messages-and-disabling-the-debug).