Content Thieves

Why Your Files Are Easy Targets

Every day, the internet pulls a fresh batch of pages, images, documents, and other files from every corner of the web. Search engines, data‑mining bots, and even casual users all hit the same URLs to grab what they need. That openness, while a core strength of the web, also leaves a lot of valuable content on the periphery, accessible by anyone who knows the address. When a piece of content sits behind a public URL, there is no extra barrier for a determined individual to copy it. Even a single click can download an entire PDF, a Word document, or a set of high‑resolution images, and the person who did it will have an identical copy that never expires, never gets deleted, and never requires permission.

In the early days, content creators relied on the fact that a file would be hard to find unless it was indexed or shared. But search engines now index everything they crawl, and the speed at which crawlers operate means that a newly uploaded file can surface on a search result within minutes. A bot that has already found a link can replicate the download many times in seconds, or even store a reference for future use. Once a file is out there, every subsequent request will be answered with the same binary data. If the data is valuable – a technical white paper, a unique image, or an e‑book – it can be reproduced without a trace, and the original author has no direct evidence of who has taken it.

It is also easy for an attacker to exploit a site's public directory structure. Most web servers expose the root directory and allow clients to request any file that resides there. Even without knowledge of the file name, an attacker can guess common file names, enumerate directories, or follow links from the site’s navigation. Because the HTTP protocol itself does not require authentication for static content, the server simply hands out whatever it finds. That means that a single URL, whether it ends in .pdf, .doc, or .jpg, can be treated as a direct download, with no user verification.

Search engines like Google are not the only ones who crawl content. Many free and paid services, academic institutions, and corporate partners also run crawlers that look for specific file types. They often ignore the site’s intended audience or any implicit permission model. In practice, the moment a file is linked, it is exposed to a large, unpredictable audience.

Because of these realities, a site that contains premium documents or proprietary images is effectively giving away its intellectual property unless it takes explicit steps to guard each file. Even a basic file‑level ACL or a simple password prompt can be bypassed by a savvy user who understands that the web is built for sharing. The only reliable protection is to intercept the request and decide at runtime whether to allow the transfer.

In the next section we will discuss why the default security mechanisms that many developers rely on are not enough to keep these files safe, and how a custom HttpHandler can give you the fine‑grained control you need.

Why Built‑in Security Falls Short

It’s tempting to think that the operating system’s file permissions or the web server’s authentication settings will stop a curious user from grabbing a PDF. In many cases they do not. For instance, if you place a PDF in a directory that is served by IIS, the default behavior is to let the file download without any checks, because static content is not mapped to ASP.NET’s authentication pipeline. Even if you set an ACL that denies all but the administrator, a user who accesses the URL directly will still receive the file – IIS simply checks that the file exists and streams it. The ACL is applied only to the file system, not to the HTTP request.

Another common mistake is relying on “security through obscurity.” Naming a file something like 903890xx0s9ki49.pdf may make it hard for a human to guess, but it offers no protection against a bot that can enumerate files, or a user who can request the URL directly after finding it. The URL is the only gate; if you can hit it, you have the file. The obscurity of the name does nothing to slow an attacker.

ASP.NET’s authentication system is powerful for dynamic pages – .aspx, .ascx, .cs, and .vb files that go through the ASP.NET runtime. When a request arrives for a mapped handler, the framework checks the configured authentication module, validates the user, and then serves the page. However, static files that are not mapped to ASP.NET bypass this process entirely. A PDF is served directly by IIS, not by ASP.NET, so the authentication module never sees it. This means that even if your application requires users to log in before they can see the rest of the site, anyone who finds the URL can still download the file.

Some developers try to wrap static content inside ASP.NET by using a handler or a custom page that streams the file. That approach works, but it requires a separate mechanism to map the extension to the handler. Without that mapping, IIS will serve the file as static content and ignore the handler. Moreover, many servers are configured to serve common file types like .pdf, .doc, or .zip directly for performance reasons, so the handler mapping may be overridden by the default static file handler.

Even if you use HTTPS, the data is still sent over the network unprotected once it reaches the client. A man‑in‑the‑middle attacker who can see the traffic will still capture the file. In many deployments, the network segment between the server and the client is not monitored, and SSL is considered the only protection. That is insufficient; you need to enforce the same protection on every request, regardless of transport.

Because of these limitations, the only way to truly protect a file is to make sure the request hits a piece of code that can decide whether the client should get the data. That code must be part of the same pipeline that handles your application’s authentication, or you must configure the server to route the file requests to it. The next section will walk you through creating that routing logic with a custom HttpHandler.

Securing Assets with a Custom HttpHandler

A custom HttpHandler gives you a hook into the ASP.NET pipeline that runs before any static file is streamed. The handler implements the IHttpHandler interface, which requires two methods: IsReusable and ProcessRequest. The IsReusable property simply tells ASP.NET whether the same handler instance can serve multiple requests – most implementations return false for safety. The ProcessRequest method receives an HttpContext object that exposes the request, the response, the session, and the user. Inside that method you decide whether to let the transfer happen.

public class AssetHandler : IHttpHandler
{
    public bool IsReusable => false;
    public void ProcessRequest(HttpContext context)
    {
        // Pull the file path from the URL
        string requestedPath = context.Request.Path;
        // Example: only allow users in the "Subscribers" role
        if (!context.User.IsInRole("Subscribers"))
        {
            // Reject the request
            context.Response.StatusCode = 403; // Forbidden
            context.Response.End();
            return;
        }
        // Ensure the file exists on disk
        string physicalPath = context.Server.MapPath(requestedPath);
        if (!File.Exists(physicalPath))
        {
            context.Response.StatusCode = 404; // Not Found
            context.Response.End();
            return;
        }
        // Set MIME type based on extension
        context.Response.ContentType = MimeMapping.GetMimeMapping(physicalPath);
        // Stream the file
        context.Response.AddHeader("Content-Disposition",
            $"attachment; filename=\"{Path.GetFileName(physicalPath)}\"");
        context.Response.TransmitFile(physicalPath);
        context.Response.End();
    }
}

Creating the handler is only the first part. You must also tell IIS that requests for specific extensions – like .pdf or .doc – should be routed to your handler instead of being served as static files. That configuration lives in web.config. Add an entry under <system.webServer> so the server knows to use your handler:

<configuration>
  <system.webServer>
    <handlers>
      <add name="AssetHandler" path="*.pdf" verb="GET" type="AssetHandler" 
           resourceType="Unspecified" preCondition="integratedMode" />
    </handlers>
  </system.webServer>
</configuration>

In this snippet the path attribute uses a wildcard to catch all PDFs, and verb="GET" ensures that only download requests are affected. The resourceType="Unspecified" tells IIS that the handler should be considered even if the file exists on disk, and preCondition="integratedMode" guarantees that the handler runs in IIS’s integrated pipeline. If you need to protect multiple file types, duplicate the <add> entry for each extension.

After adding the handler, you must compile the handler class into your application’s bin folder or into a separate assembly that the web app references. When the web server receives a request that matches the handler mapping, it will instantiate your class, call ProcessRequest, and let you decide whether to stream the file. Because you now have access to the HttpContext, you can enforce the same authentication rules that protect your dynamic content.

With this approach you no longer rely on the server’s static file rules or on filesystem ACLs. Every request is checked against your own logic. If the user is authenticated and in the correct role, the file streams. If not, you return a 403 status and stop the download. Even if an attacker finds the URL, the handler refuses to serve the content unless the user’s identity matches the criteria you set. That turns a passive “download if you have the URL” model into an active gatekeeper that can evaluate the client’s permissions on each request.

Deploying a custom handler is straightforward but powerful. Once it is in place, you can protect any file type, limit concurrent downloads, log every access attempt, and enforce rate limits if desired. The handler lives in the same code base as your application, so it benefits from the same security context, logging, and maintenance process. You also avoid the performance hit of serving static files through a generic page; the handler streams directly from disk, just as IIS would, but only after performing your checks.

Because every request goes through your code, you can also integrate additional checks – IP whitelisting, time‑based access windows, or even digital rights management (DRM) tokens – all without changing the URL structure. That gives you a flexible, maintainable solution that stays ahead of the bots and browsers that constantly scan the web for files.