-
Notifications
You must be signed in to change notification settings - Fork 1
/
index.html
275 lines (247 loc) · 11.3 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="icon" href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAQAAADZc7J/AAAA6klEQVR42qVV0Q3EIAil27CS4/S/IzBRh+HHAby78hpquEYjeUkVhVdABaLtLwoJ69YMrCRUXjTDApPAMICEeERwQPkVdLwTMJwegLXzw823No8HxdN8icKG6Pw4EBAMUjdOJ9xfArERyDKBXAQQl/AjKCmCQncA54W9uVSbnU21vUtidQlB2GSH6ZcCX1M2Aju28/52I+GPYGRlhQlWXaoPQ1+lXnR296tiDg9cmiVA1Nird66AiRBCJjrMJREakYA1HiPU/BhjEh0k6YuUvMrpx5R+zsmCki5p+aKaL+v5xpJvbfnmmm3vHwHeax0GY2/+AAAAAElFTkSuQmCC">
<title>Consider deploying cross-origin resource policy!</title>
<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Open+Sans:wght@400;800&family=Roboto+Slab:wght@100;500&display=swap" rel="stylesheet" crossorigin>
<style>
body, html {
border: 0;
margin: 0;
padding: 0;
}
h1 {
background: black;
color: white;
font: 100 40px/1.2 'Roboto Slab', sans-serif;
margin: 0 0 40px 0;
padding: 40px;
text-align: right;
}
h1 span:last-child {
font-weight: 500;
}
h2 {
font: 800 24px/1.2 'Open Sans', sans-serif;
margin: 0 auto 20px;
max-width: 750px;
padding: 0 2ch;
}
h2 code {
color: #07A;
}
h3 {
font: 800 18px/1.2 'Open Sans', sans-serif;
margin: 0 auto 20px;
max-width: 750px;
padding: 0 2ch;
text-align: right;
}
h2 a, h2 a:visited,
h3 a, h3 a:visited {
margin-right: -2ch;
text-decoration: none;
font-weight: 400;
color: #FFF;
}
h2 a, h2 a:visited { margin-left: -24px; margin-right: 4px; }
h2:hover a, h3:hover a {
color: #99F;
}
hr {
margin: 3em auto;
max-width: 750px;
}
p, ul {
font: 18px/1.2 'Open Sans', sans-serif;
margin: 0 auto 20px;
max-width: 750px;
padding: 0 2ch;
}
li {
margin: 0 0 20px 20px;
}
pre {
margin: 0 auto 20px;
padding: 20px 8px 20px 20px;
font: 24px/1.2 monospace;
max-width: 710px;
white-space: normal;
text-align: center;
background: #FCFAEE;
border: 0 solid #E0CB52;
border-width: 0 0 0 0.5em;
}
.header {
color: #905;
}
.value {
color: #07a;
}
.tldr {
background: #E9FBE9;
border: 0 solid #52E052;
border-width: 0 0 0 0.5em;
padding: 20px;
max-width: 710px;
margin: 0 auto 20px;
}
.tldr code {
display: block;
margin: 12px 0;
text-align: center;
font-size: 24px;
}
footer {
background: black;
color: white;
margin: 0;
padding: 1ch 2ch;
font: 15px/1.4 'Open Sans', sans-serif;
text-align: right;
}
footer a, footer a:visited {
font-family: monospace;
color: #52cbff;
}
</style>
<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@mikewest">
<meta name="og:title" content="Consider deploying Cross-Origin Resource Policy.">
<meta name="description" content="`Cross-Origin-Resource-Policy: same-origin` is always safe. `Cross-Origin-Resource-Policy: cross-origin` is always compatible.">
<meta name="og:description" content="`Cross-Origin-Resource-Policy: same-origin` is always safe. `Cross-Origin-Resource-Policy: cross-origin` is always compatible.">
<meta name="og:image" content="https://resourcepolicy.fyi/card.png">
</head>
<body>
<article>
<h1>
<span>Consider deploying</span><br>
<span>Cross-Origin Resource Policy</span>
</h1>
<p>
The
<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-Resource-Policy"><code class="header">Cross-Origin-Resource-Policy</code></a>
(<abbr title="Cross-Origin Resource Policy">CORP</abbr>) header allows you to control the set of
origins that are empowered to include a resource. It is a robust defense against attacks like
<a href="https://meltdownattack.com/">Spectre</a>, as it allows browsers to block a given response
before it enters an attacker's process.
</p>
<p>
The header has three values: <code class="value">same-origin</code>, <code class="value">same-site</code>, and
<code class="value">cross-origin</code>. Let's look at each:
</p>
<h2 id="same-origin">
<a href="#same-origin">§</a>
Limit usage with <code>same-origin</code> or <code>same-site</code>
</h2>
<p>
If a resource contains interesting information about a user, or is a response from an API that
you don't intend for others to use, then it's quite likely that you would be well-served by
asking the browser to ensure that it can't leak into cross-origin contexts by adding the
following response header to the relevant resources:
</p>
<pre><code><span class="header">Cross-Origin-Resource-Policy</span>: <span class="value">same-origin</span></code></pre>
<p>
Some applications can't lock themselves to a single origin, as they rely on resources shared
within a particular site. For example, consider <code>mail.example.com</code> and
<code>www.example.com</code>, which both rely on <code>single-sign-on.example.com</code> for
authentication, and <code>cdn.example.com</code> for static resources. These latter two origins
could not set <code>same-origin</code>, but they can set:
</o>
<pre><code><span class="header">Cross-Origin-Resource-Policy</span>: <span class="value">same-site</span></code></pre>
<h2 id="cross-origin">
<a href="#cross-origin">§</a>
Broadly allow usage with <code>cross-origin</code>
</h2>
<p>
Do you serve resources that you want other sites to embed? Perhaps you're running a widely-used
CDN? Perhaps you're running an in-house CDN for a small suite of related sites? Perhaps you own
a third-party widget that you want to be used broadly? In all these cases, you'll want to make
the expectation explicit by adding the following response header to the relevant resources:
</p>
<pre><code><span class="header">Cross-Origin-Resource-Policy</span>: <span class="value">cross-origin</span></code></pre>
<h2 id="corp-and-isolation">
<a href="#corp-and-isolation">§</a>
<abbr title="Cross-Origin Resource Policy">CORP</abbr> and Isolation
</h2>
<p>
Today, browsers act as though
<code><span class="header">Cross-Origin-Resource-Policy</span>: <span class="value">cross-origin</span></code>
is set on every response that lacks an explicit <abbr title="Cross-Origin Resource Policy">CORP</abbr>
header. This is a somewhat unfortunate default, and browsers are interested in shifting the
behavior for these resources to something more like <code class="value">same-origin</code>,
which will protect resources unless they explicitly opt-into being shared more widely. That
shift is going to take some time, however.
</p>
<p>
In the meantime, developers can opt-into a better default for their own pages by sending a
<a href="https://wicg.github.io/cross-origin-embedder-policy/"><code class="header">Cross-Origin-Embedder-Policy</code></a>
header, which will prevent them from loading cross-origin resources that don't explicitly
assert
<code><span class="header">Cross-Origin-Resource-Policy</span>: <span class="value">cross-origin</span></code>
(or grant full access via <abbr title="Cross-Origin Resource Sharing">CORS</abbr>. Over time,
browsers will begin requiring pages to
<a href="https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit">opt-into cross-origin isolation</a>
in order to access certain features that make side-channel attacks more effective (for example,
high-resolution timers like <code>performance.now()</code> or <code>SharedArrayBuffer</code>).
With this in mind, it seems likely that usage of
<code class="header">Cross-Origin-Embedder-Policy</code> will increase over time, and therefore
that <code class="header">Cross-Origin-Resource-Policy</code> will be important to consider when
configuring your server.
</p>
<p>
In particular, if you host resources that others depend upon, it would be an excellent idea to
explicitly assert a cross-origin resource policy so that you're not a roadblock to isolation.
Happily, doing so is pretty straightforward, and supported in all modern browsers. Even more
happily, the assertion has no effect in pre-modern browsers, so should be safe to roll out
for all your users.
</p>
<hr>
<h2>FAQ</h2>
<h3 id="acao">
I already assert <code><span class="header">Access-Control-Allow-Origin</span>: <span class="value">*</span></code>
for public resources. Do I need to add CORP too?
<a href="#acao">§</a>
</h3>
<p>
That depends on the folks that depend on you. <code>ACAO: *</code> only takes effect for requests
that were made as CORS requests, and which explicitly dropped credentials. That is,
<code><script ... crossorigin="anonymous"></code> will continue working, but
<code><script></code> will fail for developers who opt-into isolation.
You can determine how many folks are making CORS-enabled requests by taking a look at incoming
<code>Sec-Fetch-Mode</code> headers from browsers that support
<a href="https://w3c.github.io/webappsec-fetch-metadata/">Fetch Metadata</a>. It seems likely
that you'll see a mix of <code>cors</code> and <code>no-cors</code> requests. The former will
continue working for isolated sites, the latter will not.
</p>
<h3 id="browser-support">
Do modern browsers support CORP?
<a href="#browser-support">§</a>
</h3>
<p>
Yes! The three major browser engines all support the header. Safari 12 was the first to support
the header, followed by Firefox 74 and Chrome 73. Chromium-based browsers like Edge should support
it as well. A
<a href="https://caniuse.com/#feat=mdn-http_headers_cross-origin-resource-policy">more detailed support chart</a>
is available from the good folks at <a href="https://caniuse.com/">Can I use...</a>
</p>
<h3 id="isolation">
Where can I read more about this isolation thing?
<a href="#isolation">§</a>
</h3>
<p>There are a few good resources to check out:</p>
<ul>
<li>"<a href="https://web.dev/coop-coep/">Making your website 'cross-origin isolated' using COOP and COEP</a>" is an approachable introduction.</li>
<li>Chromium's "<a href="https://chromium.googlesource.com/chromium/src/+/master/docs/security/side-channel-threat-model.md">Post-Spectre Threat Model Re-Think</a>" is a good introduction to the core problem that isolation hopes to address.</li>
<li>"<a href="https://docs.google.com/document/d/1zDlfvfTJ_9e8Jdc8ehuV4zMEu9ySMCiTGMS9y0GU92k/edit">COOP and COEP Explained</a>" is a good primer on <code>Cross-Origin-Opener-Policy</code>, and <code>Cross-Origin-Embedder-Policy</code>, which form the technical basis of the opt-in.</li>
<li>The Fetch specification defines the <a href="https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header"><code>Cross-Origin-Resource-Policy</code> header</a>.</li>
</ul>
</article>
<footer>
Typos? Mistakes? Poke at <a href="https://github.com/mikewest/consider-deploying-corp">mikewest/consider-deploying-corp</a>.
</footer>
</body>
</html>