ASP.NET C# Error Page

Application_Error only runs for errors that occur inside ASP.NET
Anything blocked by IIS, HTTP.sys, or Request Filtering will never reach it.

This is actually the correct and secure behavior.

• IIS is protecting your app from XSS

• You should not disable this unless you have a very specific reason

Best practice:
Handle only valid routes inside your app
Let IIS drop malicious requests

This issue happens because IIS blocks the request before it reaches ASP.NET.

When you enter a URL like:
a%22%3E%3Cscript%3Ealert(123);%3C/script%3E

IIS treats this as a potential XSS (script injection) attack.
So IIS rejects the request at the web server level itself.

That is why:

• The page does not load
• Application_Error is not called
• ASP.NET never gets control

On your local machine, IIS Express is more relaxed, so it works there.

Why Application_Error is not firing
Application_Error runs only when ASP.NET handles the request.
In your deployed IIS server, the request is blocked earlier by:

• IIS Request Filtering
• URL Validation
• Double escaping rules

So ASP.NET pipeline is never reached.

How to fix / handle this properly (recommended way)

Option 1: Handle IIS-level errors
Configure IIS to show a custom error page for 400 / 404 / 500 errors.

In web.config:

This works even when IIS blocks the request.

Option 2: Relax request filtering (NOT recommended for production)

If you really want ASP.NET to receive such URLs:

This reduces security and should be avoided unless absolutely required.

Option 3: Use Global.asax + customErrors (ASP.NET only)

This works only for errors that reach ASP.NET:

But it will NOT handle IIS-blocked URLs.

Correct security understanding (important)

• IIS is correctly protecting your app
• Script-like URLs should NOT be allowed
• Blocking at IIS level is expected behavior
• Do not rely only on Application_Error for security

IIS itself rejects certain malformed URLs (invalid characters, double slashes, encoded fragments) before ASP.NET gets a chance to process them. That’s why doesn’t trigger — the request is blocked at the IIS level.

By default, IIS blocks requests containing <, >, ", and other dangerous sequences to mitigate XSS and injection attacks.

It’s generally good that IIS blocks these requests before they hit your app. Don’t disable filtering unless you have a strong reason (like needing to test XSS handling). Instead, configure custom error pages and rely on IIS logs for monitoring.

Options to handle this

1. Configure IIS Request Filtering

If you want ASP.NET to see these requests (for logging or custom error handling), you can relax IIS’s request filtering:

• allowDoubleEscaping="true" lets IIS pass encoded characters like %3C (<) to ASP.NET.

• Be careful: this increases exposure to malicious requests. Only enable if you need to log/analyze them.

2. Use IIS Custom Errors

Since IIS is blocking the request, configure IIS-level custom error pages:

This way, even if ASP.NET never sees the request, IIS will show a friendly error page instead of a raw 400/404.

3. Centralized Logging

If your goal is logging attacks/garbage URLs:

• Use IIS logs (enabled by default) — they capture rejected requests.

• Consider a WAF (Web Application Firewall) or middleware logging at the reverse proxy level.

4. Keep Application_Error for ASP.NET exceptions

Remember: Application_Error only catches exceptions inside the ASP.NET pipeline. For IIS-level rejections, you must rely on IIS custom errors or logs.

• Leave IIS request filtering ON (default).

• Add custom error pages for 400/404.

• Use IIS logs for monitoring garbage/malicious requests.