Solid data pods disable all cross-origin protections in browsers because resource access is governed explicitly by Web Access Control. As such, data pods MUST NOT rely on browser-based cross-origin protection mechanisms for determining the authentication status or representation of a resource. In particular, they MUST ignore HTTP cookies from untrusted origins. Additional security measures MAY be taken to prevent metadata in error responses from leaking. For instance, a malicious app could probe multiple servers to check whether the response status code is 401 or 403, or could try to access an error page from an intranet server within the user agent’s private network to extract company names or other data. To mitigate this, when a request from an untrusted Origin arrives, the data pod MAY set the status code of error responses to 404 and/or anonymize or censor their contents.
Data pods SHOULD use TLS connections to protect the contents of requests and responses from eavesdropping and modification by third parties. Unsecured TCP connections without TLS MAY be used in testing environments or when the data pod is behind a reverse proxy that terminates a secure connection.
+ +Servers MUST NOT expose information beyond the minimum amount necessary to enable a feature. For example, when a GET method request targets a container, the server MUST NOT include information beyond containment statements about the contained resources in the response. Examples of what is not allowed without proper authorization include size, type, creator, label, and last modification time.