HTTP Error 403.14 - Forbidden: IIS Directory Listing

The error text tells you what to do, and it’s the one thing you shouldn’t.

HTTP Error 403.14 - Forbidden. The Web server is configured to not list the contents of this directory.

Read literally, that sentence practically begs you to go turn on directory listing. Do that and the error vanishes — replaced by a public, clickable index of every file in the folder: your source, your web.config, whatever backups happen to be sitting there. You didn’t fix the problem. You published your directory tree and buried the real cause under it.

What 403.14 actually means

The digits after the dot are an IIS substatus, and they’re specific. A plain 403 — or 403.1 through 403.12 — is a real access denial: NTFS permissions, an IP restriction, an authorization rule saying no. 403.14 is a different animal, and it’s almost mechanical. It fires when three things are all true at once:

1. The URL points at a directory, not a specific file (/app/ rather than /app/index.html).
2. That directory has no default document IIS is willing to serve.
3. Directory Browsing is off (the safe default).

So IIS is holding a request for a folder, has no document to hand back, and isn’t allowed to list the folder. With nothing to serve, it returns 403.14. Notice what’s not involved: this has nothing to do with your identity or permissions. It’s “there is nothing here to send you,” dressed up as “Forbidden.”

The two things it’s really telling you

Once you stop reading 403.14 as an access problem, it splits cleanly into two causes.

It’s a static site and you genuinely have no landing document. You deployed a folder, requests come in for /, and there’s no index.html or default.aspx for IIS to pick up. The fix is to add a default document — open the site in IIS Manager, double-click Default Document, and make sure the file you actually shipped is in the list and near the top. IIS matches the list top to bottom, so if index.htm sits above the index.html you deployed, it keeps looking. This is the honest, boring case.

It’s an application, and the request died before the app ever saw it. This is the one that confuses people, because they know the pages exist. An ASP.NET MVC or ASP.NET Core app serves extensionless URLs like /products/42 — there is no file at that path. Routing to a controller is the framework’s job, and the framework only gets the request if IIS hands it into the managed pipeline. When 403.14 shows up for an app that clearly has pages, it means IIS looked for a file at that path, found none, found no default document, and quit — before routing ran. It’s a 404 wearing a 403.14 mask.

The reason IIS never handed the request over is a registration problem, not a browsing problem:

• The application pool is in the wrong mode, or ASP.NET was never registered with IIS. On older .NET, that’s what aspnet_regiis -i fixed; the modern equivalent is making sure the correct .NET hosting components are installed and the pool’s pipeline mode matches the app.
• For ASP.NET Core, the site’s web.config is missing or broken, so the ASP.NET Core Module handler that forwards requests to your app (Kestrel) never engages. A publish that didn’t emit web.config, or one that got overwritten, produces exactly this.

You’ll see advice to set runAllManagedModulesForAllRequests="true". That can make an app start responding, but it’s a blunt instrument — it forces every request, including static files, through the managed pipeline, which is slower and not what you want long-term. It’s a symptom mask, like enabling Directory Browsing. Fix the handler registration so extensionless requests reach the framework the intended way.

Confirm it from outside

• HTTP Header Check fetches the URL and shows you the real status line and response headers from outside your network. Use it to confirm you’re actually getting a 403.14 (and from IIS, not a proxy or load balancer in front of it), and to check the response after each change instead of trusting a possibly-cached browser tab.

Checklist

• Read the substatus: 403.14 is “no document to serve here,” not “you’re not allowed.” Don’t treat it as a permissions problem.
• If it’s a static site, add the correct default document and move it above any wrong defaults in the list.
• If it’s an app with real pages, the request isn’t reaching your code — check the application pool mode, that ASP.NET/.NET hosting is installed and registered, and that a valid web.config with the app’s handler is deployed.
• Do not enable Directory Browsing to make it go away — that exposes your files and hides the real fault.
• Re-check the URL from outside after each change so you’re testing the server, not a cached page.