4. Security Considerations

Applications minting new well-known URIs, as well as administrators deploying them, will need to consider several security-related issues, including (but not limited to) exposure of sensitive data, denial-of-service attacks (in addition to normal load issues), server and client authentication, vulnerability to DNS rebinding attacks, and attacks where limited access to a server grants the ability to affect how well-known URIs are served.

[RFC3552] contains some examples of potential security considerations that may be relevant to application protocols and administrators deploying them.

4.1. Protecting Well-Known Resources

Because well-known locations effectively represent the entire origin, server operators should appropriately control the ability to write to them. This is especially true when more than one entity is co-located on the same origin. Even for origins that are controlled by and represent a single entity, due care should be taken to assure that write access to well-known locations is not granted unwittingly, either externally through server configuration or locally through implementation permissions (e.g., on a filesystem).

4.2. Interaction with Web Browsing

Applications using well-known URIs for http or https URLs need to be aware that well-known resources will be accessible to Web browsers, and therefore are able to be manipulated by content obtained from other parts of that origin. If an attacker is able to inject content (e.g., through a Cross-Site Scripting vulnerability), they will be able to make potentially arbitrary requests to the well-known resource.

HTTP and HTTPS also use origins as a security boundary for many other mechanisms, including (but not limited to) cookies [RFC6265], Web Storage [WEBSTORAGE], and various capabilities.

An application that defines well-known locations should not assume that it has sole access to these mechanisms or that it is the only application using the origin. Depending on the nature of the application, mitigations can include:

Encrypting sensitive information
Allowing flexibility in the use of identifiers (e.g., cookie names) to avoid collisions with other applications
Using the HttpOnly flag on cookies to assure that cookies are not exposed to browser scripting languages [RFC6265]
Using the Path parameter on cookies to assure that they are not available to other parts of the origin [RFC6265]
Using X-Content-Type-Options: nosniff [FETCH] to assure that content under attacker control can't be coaxed into a form that is interpreted as active content by a Web browser

Other good practices include:

Using an application-specific media type in the Content-Type header field, and requiring clients to fail if it is not used
Using Content-Security-Policy [CSP] to constrain the capabilities of active content (such as HTML [HTML5]), thereby mitigating Cross-Site Scripting attacks
Using Referrer-Policy [REFERRER-POLICY] to prevent sensitive data in URLs from being leaked in the Referer request header field
Avoiding use of compression on any sensitive information (e.g., authentication tokens, passwords), as the scripting environment offered by Web browsers allows an attacker to repeatedly probe the compression space; if the attacker has access to the path of the communication, they can use this capability to recover that information.

4.3. Scoping Applications

This memo does not specify the scope of applicability for the information obtained from a well-known URI, and does not specify how to discover a well-known URI for a particular application.

Individual applications using this mechanism must define both aspects; if this is not specified, security issues can arise from implementation deviations and confusion about boundaries between applications.

Applying metadata discovered in a well-known URI to resources other than those co-located on the same origin risks administrative as well as security issues. For example, allowing https://example.com/.well-known/example to apply policy to https://department.example.com, https://www.example.com, or even https://www.example.com:8000 assumes a relationship between hosts where there might be none, thereby giving control to a potential attacker.

Likewise, specifying that a well-known URI on a particular hostname is to be used to bootstrap a protocol can cause a large number of undesired requests. For example, if a well-known HTTPS URI is used to find policy about a separate service such as email, it can result in a flood of requests to Web servers, even if they don't implement the well-known URI. Such undesired requests can resemble a denial-of-service attack.

4.4. Hidden Capabilities

Applications using well-known locations should consider that some server administrators might be unaware of their existence (especially on operating systems that hide directories whose names begin with .). This means that if an attacker has write access to the .well-known directory, they would be able to control its contents, possibly without the administrator realising it.