Information exposure through Link header by guessing an allocated URI

既存パスと存在しないパスについて、GET リクエストの処理と Link ヘッダーの生成を追跡します。/foo/bar と /foo/baz に対する未認証リクエストと未認可リクエストを比較します。完了条件は、これらの拒否されたリクエストで Link ヘッダーが一貫して存在せず、意図された情報開示の挙動がテストでカバーされていることです。

NSS responds to unauthenticated and unauthorized GET requests to /foo/bar (that exists) by including the HTTP header:

Link: <bar.acl>; rel="acl", <bar.meta> rel="describedBy", <http://www.w3.org/ns/ldp#Resource>; rel="type"

For GET requests to non-existing resources eg. /foo/baz, the response doesn't include the HTTP Link header.

Thus, the security consideration: existence of a resource can potentially be known by guessing or anticipating an allocated URI.

There are use cases where the server may want to reveal the information in the Link header in the response. If the server doesn't make the distinction between intentionally revealing and unintentionally exposing, the server is encouraged to minimize information leaking. So, in the case here, it should be consistent by omitting the Link header for unauthenticated and unauthorized requests.