XEP-0156: Add implementation notes suggesting CORS

Adding `Access-Control-Allow-Origin: *` header allows web clients hosted
on different domains access connection settings for target servers.

This change adds similar suggestion that is already present in XEP-0363
HTTP Upload [0].

See: https://mail.jabber.org/pipermail/standards/2019-January/035645.html
See: https://mail.jabber.org/pipermail/standards/2019-February/035778.html

[0]: https://xmpp.org/extensions/xep-0363.html#impl
Wiktor Kwapisiewicz 2019-01-17 16:25:03 +01:00
parent df4016117d
commit 160145b915
No known key found for this signature in database
GPG Key ID: B97A1EE09DB417EC
1 changed files with 8 additions and 1 deletions

View File

@ -231,7 +231,14 @@ _xmppconnect IN TXT "_xmpp-client-websocket=wss://web.example.com:443/ws"
<section1 topic='Implementation Notes' anchor='impl'>
<p>To make connection discovery work in web clients (including those hosted on a different domain) the host service SHOULD set appropriate <link url="https://www.w3.org/TR/cors/">CORS</link> headers for Web Host Metadata files. The exact headers and values are out of scope of this document but may include: <em>Access-Control-Allow-Origin</em>, <em>Access-Control-Allow-Methods</em> and <em>Access-Control-Allow-Headers</em>.</p>
<p>Due care has to be exercised in limiting the scope of <em>Access-Control-Allow-Origin</em> response header to Web Host Metadata files only.</p>
<code caption="Example header allowing all sites to read host metadata"><![CDATA[
Access-Control-Allow-Origin: *
<p class="box"><em>Access-Control-Allow-Origin</em> header with a value of <em>*</em> allows JavaScript code running on a different domain to read the content of Web Host Metadata files. Special value <em>*</em> ensures that the request will only succeed if it is <link url="https://www.w3.org/TR/cors/#resource-requests">invoked without user credentials</link> (e.g. cookies, HTTP authentication).</p>
<section1 topic='Security Considerations' anchor='security'>
<p>It is possible that advertisement of alternative connection methods can introduce security vulnerabilities, since a connecting entity (usually a client) might deliberately seek to connect using the method with the weakest security mechanisms (e.g., no channel encryption or relatively weak authentication). Care needs to be taken in determining which alternative connection methods are appropriate to advertise.</p>
<p>Entities that use these connection methods MUST conform to the security considerations of each method, for example by preferring to use 'https' or 'wss' URLs that are protected using Transport Layer Security (TLS).</p>