The global Browser directory and the application-level App_Browsers subdirectory should contain only files with the file name extension .browser. Only .browser files are compiled by the ASP.NET browser capabilities feature. Additionally, ASP.NET protects the files in these directories from being served by the Web server and from being accessed by code in other applications.

The following table lists the ACLs that are set by default on the .browser files located in the %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers directory. These ACLs are also set on the directory itself, but they include Modify permissions for the CREATOR OWNER group. The directory is read only.

The following table lists the ACLs that should be set on application-level .browser files in the App_Browsers subdirectory.

Do not download or install browser definition files unless you trust their source. For example, examine a new browser definition file to see if any unfamiliar namespaces are referenced in any of the following attributes:

• The markupTextWriterType attribute of the controlAdapters element.

• The value attribute of the capability element.

• The controlType and adapterType attributes of the adapter element.

For information about valid elements and attributes, see Browser Definition File Schema (browsers Element).

If you add new browser definition files to the global directory or if you make changes to global browser definition files, those changes have no effect until you manually recompile the browser capabilities collection using the Aspnet_regbrowsers.exe tool, available in the %SystemRoot%\Microsoft.NET\Framework\version folder, or programmatically cause recompilation by using the BrowserCapabilitiesCodeGenerator class.

However, you do not need to recompile changes to application-level browser definitions. Changes to those definitions are recompiled and reapplied dynamically.

Only multiple attempts to save to a browser definition file or open a file handle can lock a browser definition file. A malicious user might attempt to lock the browser definition files in the %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers directory. However, locking a browser definition file requires Full trust, which is disabled in ASP.NET by default.

The classes of the browser definition configuration API cannot read any directories that are not part of the application domain, or any files that do not have a .browser file name extension.

At run time, browser definition file information is merged into a collection of known browsers in a BrowserCapabilitiesFactory object. When a request is made, ASP.NET identifies the requesting browser by the request header and compiles an HttpCapabilitiesBase object that corresponds to the requesting browser. The object is cached and might be used again for a different request made by the same browser.

A malicious client might try to flood your Web server with requests where each new request uses a different request header, causing ASP.NET to generate and cache browser capability objects for each request, which in turn can result in a denial-of-service attack. To mitigate this threat, configure the userAgentCacheKeyLength attribute of the browserCaps Element (ASP.NET Settings Schema) element in the Machine.config file or a Web.config file. This element defines the character length to use as the key to identify cached capabilities objects in the internal cache. The default is 64. You can reduce this value to make it more likely that a matching browser will be found in the cache, reducing the load on the cache.