If you’ve ever had a developer, tell you that they have secured the access by using long complex, and difficult to guess names such as a GUIDv4 9f8a3c2e-7d4b-4a1f-9b2e-8c3d9e2f1a7b.xlsx you’re not alone. Many developers and websites use this exact strategy to attempt to protect sensitive files. It’s called “security through obscurity,” and while it does not prevent unauthorised access, it can reduce the likely hood that someone can guess or brute force the filename…. Or so it seems.

There is a legacy feature in Windows that breaks this illusion of security: NTFS 8.3 naming.

What Is NTFS 8.3 Naming?

In the early days of computing, file names had to be short—eight characters for the name, three for the extension (like .txt). To stay compatible with older systems, Windows still creates these short versions of file and folder names behind the scenes.

So, while your file path might be:

C:\inetpub\wwwroot\SuperSecureFiles\9f8a3c2e-7d4b-4a1f-9b2e-8c3d9e2f1a7b.xlsx

Windows might also create a shortcut like:

C:\inetpub\wwwroot\SUPERS~1\9F8A3C~1.xls

That short name is much easier to guess, and that’s where the risk begins.

How This Impacts Your Website

Let’s say your website is hosted on an IIS server with the address of https://example.com, and you’ve placed sensitive files as the GUID as above. You expect users (or attackers) would need to know the full URL:

https://example.com/SuperSecureFiles/9f8a3c2e-7d4b-4a1f-9b2e-8c3d9e2f1a7b.xlsx

But if NTFS 8.3 naming is enabled, someone could try:

https://example.com/SUPERS~1/9F8A3C~1.xls

And by default, IIS will allow the file to be downloaded without any form of Authentication.

Why This Matters

Many developers hosting sites in IIS websites rely on long, obscure folder and file names to protect sensitive content. It’s a simple way to reduce the risk of brute-force guessing. But NTFS 8.3 naming quietly creates a side effect, making those folders and files easier to discover.

This is especially important for sites that:

• Store private downloads, uploads, or configuration files
• Use GUIDs (long random strings) to obscure folder names
• Operate in regulated industries where data protection matters

What You Can Do

If you’re using IIS and relying on long folder names for security, you are at risk of simple or easy discovery. A workaround is to update the configuration of the IIS web.config to something such as this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <security>
        <requestFiltering>
          <fileExtensions>
            <add fileExtension=".doc" allowed="false" />
            <add fileExtension=".xls" allowed="false" />
            <add fileExtension=".pdf" allowed="false" />
          </fileExtensions>
          <hiddenSegments>
            <add segment="wwwroot/SuperSecureFiles" />
          </hiddenSegments>
        </requestFiltering>
      </security>
    </system.webServer>
  </location>
</configuration>
<!-- This may require tweaking depending on your actual web.config -->

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <security>
        <requestFiltering>
          <fileExtensions>
            <add fileExtension=".doc" allowed="false" />
            <add fileExtension=".xls" allowed="false" />
            <add fileExtension=".pdf" allowed="false" />
          </fileExtensions>
          <hiddenSegments>
            <add segment="wwwroot/SuperSecureFiles" />
          </hiddenSegments>
        </requestFiltering>
      </security>
    </system.webServer>
  </location>
</configuration>
<!-- This may require tweaking depending on your actual web.config -->

This is a work around, and should not be relied upon. The correct action is to relocate all of the files that are under the /SuperSecureFiles directory to a location outside of wwwroot and use a controller to ensure that a request is authorised to access the file(s).