Skip to content

Improve SSRF security considerations #49

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Improve SSRF security considerations #49

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fcc7a4c
Improve SSRF security considerations
btiernay Sep 29, 2025
bfc09b5
Add normative reference to RFC6890
ThisIsMissEm Sep 29, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions draft-parecki-oauth-client-id-metadata-document.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,7 @@ normative:
RFC3986:
RFC6749:
RFC6819:
RFC6890:
RFC7591:
RFC8414:
RFC9700:
Expand Down Expand Up @@ -153,6 +154,8 @@ client name and logo.
The authorization server SHOULD fetch the document indicated by the `client_id`
to retrieve the client registration information.

Special care should be taken to avoid Server Side Request Forgery (SSRF) Attacks when fetching Client ID Metadata Documents, as noted in {{ssrf_attacks}}.

## Client Metadata

The client metadata document URL is a JSON document containing the metadata
Expand Down Expand Up @@ -286,9 +289,11 @@ The authorization server SHOULD display the hostname of the `client_id` on the a
If fetching the client metadata document fails for any reason, the `client_id` URL is the only piece of information the user has as an indication of which application they are authorizing.


## Server Side Request Forgery (SSRF) Attacks
## Server Side Request Forgery (SSRF) Attacks {#ssrf_attacks}

Authorization servers fetching the client metadata document and resolving URLs located in the metadata document should be aware of possible SSRF attacks. Authorization servers MUST validate that the Client ID Metadata Document URL does not resolve to special-use IP addresses as defined in [RFC6890], except when the authorization server itself is also running on a loopback address and the resolved address matches the same loopback interface.
Copy link
Contributor Author

@ThisIsMissEm ThisIsMissEm Sep 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may want to go further here, like Bluesky's AT Proto, by verifying that the hostname has at least two components, and prevents usage of the following TLDs:

  • .test
  • .local
  • .localhost
  • .invalid
  • .example

However, these TLDs may be useful when developing locally the AS and Client.


Authorization servers fetching the client metadata document and resolving URLs located in the metadata document should be aware of possible SSRF attacks. Authorization servers SHOULD avoid fetching any URLs using private or loopback addresses and consider network policies or other measures to prevent making requests to these addresses. Authorization servers SHOULD also be aware of the possibility that URLs might be non-http-based URI schemes which can lead to other possible SSRF attack vectors.
Authorization servers SHOULD avoid fetching any URLs contained within Client ID Metadata Documents that resolve to special-use IP addresses as defined in [RFC6890] and consider network policies or other measures to prevent making requests to these addresses. Authorization servers SHOULD also be aware of the possibility that URLs might be non-http-based URI schemes which can lead to other possible SSRF attack vectors.


## Maximum Response Size for Client Metadata Documents
Expand Down