Copyright © 2010-2012 W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This
is
the
Last
Call
Working
Draft
of
the
CSP
1.0
specification.
It
document
describes
a
proposal
that
has
been
discussed
by
the
broader
community
for
about
two
years.
since
2010
There
are
experimental
implementations
in
Firefox
and
Chrome,
using
the
header
names
X-Content-Security-Policy
and
X-WebKit-CSP
respectively.
Internet
Explorer
10
Platform
Preview
also
contains
a
partial
implementation,
using
the
header
name
X-Content-Security-Policy.
X-Content-Security-Policy
.
In
addition
to
the
documents
in
the
W3C
Web
Application
Security
working
group,
the
work
on
this
document
is
also
informed
by
the
work
of
the
IETF
websec
working
group
,
particularly
that
working
group's
requirements
document:
draft-hodges-websec-framework-reqs
.
The
websec
working
group
is
also
considering
a
document
that
defines
the
Content-Security-Policy
header
field:
http://tools.ietf.org/html/draft-gondrom-websec-csp-header
.
This
document
was
published
by
the
Web
Application
Security
Working
Group
as
a
Working
Draft.
Candidate
Recommendation.
This
document
is
intended
to
become
a
W3C
Recommendation.
If
you
wish
to
make
comments
regarding
this
document,
please
send
them
to
public-webappsec@w3.org
(
subscribe
,
archives
).
The
deadline
for
comments
on
this
Last
Call
Working
Draft
W3C
publishes
a
Candidate
Recommendation
to
indicate
that
the
document
is
24
August
believed
to
be
stable
and
to
encourage
implementation
by
the
developer
community.
This
Candidate
Recommendation
is
expected
to
advance
to
Proposed
Recommendation
no
earlier
than
30
November
2012.
All
feedback
is
welcome.
A
diff-marked
version
against
the
previous
version
of
this
document
is
available.
Publication
as
a
Working
Draft
Candidate
Recommendation
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implementation all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This section is non-normative.
This
document
defines
Content
Security
Policy,
a
mechanism
web
applications
can
use
to
mitigate
a
broad
class
of
content
injection
vulnerabilities,
such
as
cross-site
scripting
(XSS).
Content
Security
Policy
is
a
declarative
policy
that
lets
the
authors
(or
server
administrators)
of
a
web
application
restrict
inform
the
client
from
where
the
application
can
expects
to
load
resources.
To
mitigate
XSS,
for
example,
a
web
application
can
restrict
itself
to
loading
scripts
only
declare
from
known,
trusted
URIs,
making
where
it
difficult
for
an
attacker
who
can
inject
content
into
expects
to
load
scripts,
allowing
the
web
application
client
to
inject
detect
and
block
malicious
script.
scripts
injected
into
the
application
by
an
attacker.
Content Security Policy (CSP) is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth, to reduce the harm caused by content injection attacks.
There is often a non-trivial amount of work required to apply CSP to an existing web application. To reap the greatest benefit, authors will need to move all inline script and style out-of-line, for example into external scripts, because the user agent cannot determine whether an inline script was injected by an attacker.
To
take
advantage
of
CSP,
a
web
application
opts
into
using
CSP
by
supplying
a
Content-Security-Policy
HTTP
header
Such
policies
apply
the
current
resource
representation
only.
To
supply
a
policy
for
an
entire
site,
the
server
needs
to
supply
a
policy
with
each
resource
representation.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words must , must not , required , should , should not , recommended , may , and optional in this specification are to be interpreted as described in [ RFC2119 ].
Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word (" must ", " should ", " may ", etc) used in introducing the algorithm.
A conformant user agent must implement all the requirements listed in this specification that are applicable to user-agents, and may implement those marked as "(Optional)".
A conformant server must implement all the requirements listed in this specification that are applicable to servers.
This section defines several terms used throughout the document.
The term security policy , or simply policy , for the purposes of this specification refers to either:
The security policies defined by this document are applied by a user agent on a per-resource representation basis . Specifically, when a user agent receives a policy along with the representation of a given resource, that policy applies to that resource representation only . This document often refers to that resource representation as the protected resource .
A
server
transmits
its
security
policy
for
a
particular
protected
resource
as
a
collection
of
directives
,
such
as
default-src
'self'
,
each
of
which
controls
declares
a
specific
set
of
privileges
restrictions
for
that
protected
resource
as
instantiated
by
the
user
agent.
More
details
are
provided
in
the
directives
section.
A directive consists of a directive name , which indicates the privileges controlled by the directive, and a directive value , which specifies the restrictions the policy imposes on those privileges.
The term origin is defined in the Origin specification. [ RFC6454 ]
The term URI is defined in the URI specification. [ URI ]
The term resource representation is defined in the HTTP 1.1 specification. [ HTTP11 ]
The
<script>
,
<object>
,
<embed>
,
<img>
,
<video>
,
<audio>
,
<source>
,
<track>
,
<link>
,
<applet>
,
<frame>
and
<iframe>
elements
are
defined
in
the
HTML5
specification.
[
HTML5
]
A plugin is defined in the HTML5 specification. [ HTML5 ]
The
@font-face
Cascading
Style
Sheets
(CSS)
rule
is
defined
in
the
CSS
Fonts
Module
Level
3
specification.
[
CSS3FONT
]
The
XMLHttpRequest
object
is
defined
in
the
XMLHttpRequest
specification.
[
XMLHTTPREQUEST
]
The
WebSocket
object
is
defined
in
the
WebSocket
specification.
[
WEBSOCKETS
]
The
EventSource
object
is
defined
in
the
EventSource
specification.
[
EVENTSOURCE
]
The Augmented Backus-Naur Form (ABNF) notation used in this document is specified in RFC 5234. [ ABNF ]
This document also uses the ABNF extension "#rule" as defined in HTTP 1.1. [ HTTP11 ]
The
following
core
rules
are
included
by
reference,
as
defined
in
[
ABNF
Appendix
B.1
]:
ALPHA
(letters),
DIGIT
(decimal
0-9),
WSP
(white
space)
and
VCHAR
(printing
characters).
This section defines the general framework for content security policies, including the delivery mechanisms and general syntax for policies. The next section contains the details of the specific directives introduced in this specification.
The server delivers the policy to the user agent via an HTTP response header.
Content-Security-Policy
Header
Field
The
Content-Security-Policy
header
field
is
the
preferred
mechanism
for
delivering
a
CSP
policy.
"Content-Security-Policy:" 1#policy
A
server
may
send
more
than
one
HTTP
header
field
named
Content-Security-Policy
with
a
given
resource
representation.
A
server
may
send
different
Content-Security-Policy
header
field
values
with
different
representations
of
the
same
resource
or
with
different
resources.
Upon
receiving
an
HTTP
response
containing
at
least
one
Content-Security-Policy
header
field,
the
user
agent
must
enforce
each
of
the
policies
contained
in
each
such
header
field.
Content-Security-Policy-Report-Only
Header
Field
The
Content-Security-Policy-Report-Only
header
field
lets
servers
experiment
with
policies
by
monitoring
(rather
than
enforcing)
a
policy.
"Content-Security-Policy-Report-Only:" 1#policy
For
example,
a
server
operators
might
wish
to
develop
their
security
policy
iteratively.
The
operators
can
deploy
a
report-only
policy
based
on
their
best
estimate
of
how
their
site
behaves.
If
their
site
violates
this
policy,
instead
of
breaking
the
site,
the
user
agent
will
send
violation
reports
to
a
URI
specified
in
the
policy.
Once
a
site
has
confidence
that
the
policy
is
appropriate,
they
start
enforcing
the
policy
using
the
Content-Security-Policy
header
field.
A
server
may
send
more
than
one
HTTP
header
field
named
Content-Security-Policy-Report-Only
with
a
given
resource
representation.
A
server
may
send
different
Content-Security-Policy-Report-Only
header
field
values
with
different
representations
of
the
same
resource
or
with
different
resources.
Upon
receiving
an
HTTP
response
containing
at
least
one
Content-Security-Policy-Report-Only
header
field,
the
user
agent
must
monitor
each
of
the
policies
contained
in
each
such
header
field.
A
CSP
policy
consists
of
a
U+003B
SEMICOLON
(
;
)
delimited
list
of
directives:
policy = [ directive *( ";" [ directive ] ) ]
Each directive consists of a directive-name and (optionally) a directive-value :
directive = *WSP [ directive-name [ WSP directive-value ] ] directive-name = 1*( ALPHA / DIGIT / "-" ) directive-value = *( WSP / <VCHAR except ";" and ","> )
To parse a CSP policy policy , the user agent must use an algorithm equivalent to the following:
;
):
Many CSP directives use a value consisting of a source list .
Each
source
expression
in
the
source
list
represents
a
location
from
which
content
of
the
specified
type
can
be
retrieved.
For
example,
the
source
expression
'self'
represents
the
set
of
URIs
which
are
in
the
same
origin
as
the
protected
resource
and
the
source
expression
'unsafe-inline'
represents
content
supplied
inline
in
the
resource
itself.
source-list = *WSP [ source-expression *( 1*WSP source-expression ) *WSP ] / *WSP "'none'" *WSP source-expression = scheme-source / host-source / keyword-source scheme-source = scheme ":" host-source = [ scheme "://" ] host [ port ] ext-host-source = host-source "/" *( <VCHAR except ";" and ","> ) ; ext-host-source is reserved for future use. keyword-source = "'self'" / "'unsafe-inline'" / "'unsafe-eval'" scheme = <scheme production from RFC 3986> host = "*" / [ "*." ] 1*host-char *( "." 1*host-char ) host-char = ALPHA / DIGIT / "-" port = ":" ( 1*DIGIT / "*" )
To parse a source list source list , the user agent must use an algorithm equivalent to the following:
'none'
(including
the
quotation
marks),
return
the
empty
set.
source-expression
or
ext-host-source
,
add
the
token
to
the
set
of
source
expressions
.
To check whether a URI matches a source expression , the user agent must use an algorithm equivalent to the following:
*
),
then
return
does
match
.
scheme-source
:
scheme
,
return
does
match
.
host-source
or
ext-host-source
:
scheme
that
is
not
a
case
insensitive
match
for
uri-scheme
,
then
return
does
not
match
.
scheme
and
if
uri-scheme
is
not
a
case
insensitive
match
for
the
scheme
of
the
protected
resource's
URI,
then
return
does
not
match
.
host
is
an
U+002A
ASTERISK
character
(
*
)
and
the
remaining
characters,
including
the
leading
U+002E
FULL
STOP
character
(
.
),
are
not
a
case
insensitive
match
for
the
rightmost
characters
of
uri-host
,
then
return
does
not
match
.
host
,
then
return
does
not
match
.
port
and
uri-port
is
not
the
default
port
for
uri-scheme
,
then
return
does
not
match
.
port
that
(a)
does
not
contain
an
U+002A
ASTERISK
character
(
*
)
and
(b)
does
not
represent
the
same
number
as
uri-port
,
then
return
does
not
match
.
'self'
(including
the
quotation
marks),
then
return
does
match
if
the
URI
has
the
same
scheme,
host,
and
port
as
the
protected
resource's
URI
(using
the
default
port
for
the
appropriate
scheme
if
either
or
both
URIs
are
missing
ports).
A
URI
matches
a
source
list
,
if,
and
only
if,
the
URI
matches
at
least
one
source
expression
in
the
set
of
source
expressions
obtained
by
parsing
the
source
list
.
Notice
that
no
URIs
match
an
empty
set
of
source
expressions,
such
as
the
set
obtained
by
parsing
the
source
list
'none'
.
To enforce a CSP policy, the user agent must parse the policy and enforce each of the directives contained in the policy, where the specific requirements for enforcing each directive are defined separately for each directive (See Directives , below).
Generally speaking, enforcing a directive prevents the protected resource from performing certain actions, such as loading scripts from URIs other than those indicated in a source list. These restrictions make it more difficult for an attacker to abuse an injection vulnerability in the resource because the attacker will be unable to usurp the resource's privileges that have been restricted in this way.
Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.
To monitor a CSP policy, the user agent must parse the policy and monitor each of the directives contained in the policy.
Monitoring a directive does not prevent the protected resource from undertaking any actions. Instead, any actions that would have been prevented by the directives are instead reported to the developer of the web application. Monitoring a CSP policy is useful for testing whether enforcing the policy will cause the web application to malfunction.
A
server
may
cause
user
agents
to
monitor
one
policy
while
enforcing
another
policy
by
returning
both
Content-Security-Policy
and
Content-Security-Policy-Report-Only
header
fields.
For
example,
if
a
server
operator
is
using
one
policy
but
wishes
to
experiment
with
a
stricter
policy,
the
server
operator
can
monitor
the
stricter
policy
while
enforcing
the
original
policy.
Once
the
server
operator
is
satisfied
that
the
stricter
policy
does
not
break
the
web
application,
the
server
operator
can
start
enforcing
the
stricter
policy.
If the user agent monitors or enforces a CSP policy that does not contain any directives, the user agent should report a warning message in the developer console.
If the user agent monitors or enforces a CSP policy that contains an unrecognized directive, the user agent should report a warning message in the developer console indicating the name of the unrecognized directive.
Whenever a user agent runs a worker : [ WEBWORKERS ]
This section describes the content security policy directives introduced in this specification.
In order to protect against Cross-Site Scripting (XSS), web application authors should include
script-src
and
object-src
directives,
or
default-src
directive,
which
covers
both
scripts
and
plugins.
In
either
case,
authors
should
not
include
'unsafe-inline'
in
their
CSP
policies
if
they
wish
to
protect
themselves
against
XSS.
default-src
The
default-src
directive
sets
a
default
source
list
for
a
number
of
directives.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "default-src" directive-value = source-list
Let the default sources be the result of parsing the directive's value as a source list .
To
enforce
the
default-src
directive,
the
user
agent
must
enforce
the
following
directives:
If not specified explicitly in the policy, the directives listed above will use the default sources .
script-src
The
script-src
directive
restricts
which
scripts
the
protected
resource
can
execute.
The
directive
also
controls
other
resources,
such
as
XSLT
style
sheets
[
XSLT
],
which
can
cause
the
user
agent
to
execute
script.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "script-src" directive-value = source-list
If
the
policy
contains
an
explicit
script-src
,
let
the
allowed
script
sources
be
the
result
of
parsing
the
directive's
value
as
a
source
list
.
Otherwise,
let
the
allowed
script
sources
be
the
default
sources
If
'unsafe-inline'
is
not
in
allowed
script
sources
:
script
element
or
from
an
inline
event
handler),
instead
the
user
agent
must
not
execute
script.
javascript
URI,
instead
the
user
agent
must
not
execute
the
script.
(The
user
agent
should
execute
script
contained
in
"bookmarklets"
even
when
enforcing
this
restriction.)
If
'unsafe-eval'
is
not
in
allowed
script
sources
:
eval
and
function
eval
must
throw
a
security
exception.
[
ECMA-262
]
Function
must
throw
a
security
exception.
[
ECMA-262
]
setTimeout
function
must
return
zero
without
creating
a
timer.
setInterval
function
must
return
zero
without
creating
a
timer.
The term callable refers to an object whose interface has one or more callers as defined in the Web IDL specification [ WEBIDL ].
Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed script sources , the user agent must act as if it had received an empty HTTP 400 response :
src
attribute
of
a
script
element
or
when
processing
the
Worker
or
SharedWorker
constructors.
<?xml-stylesheet?>
processing
directive
in
an
XML
document
[
XML11
],
the
href
attributes
on
<xsl:include>
element,
or
the
href
attributes
on
<xsl:import>
element.
object-src
The
object-src
directive
restricts
from
where
the
protected
resource
can
load
plugins.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "object-src" directive-value = source-list
If
the
policy
contains
an
explicit
object-src
,
let
the
allowed
object
sources
be
the
result
of
parsing
the
directive's
value
as
a
source
list
.
Otherwise,
let
the
allowed
object
sources
be
the
default
sources
Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed object sources , the user agent must act as if it had received an empty HTTP 400 response :
data
attribute
of
an
object
element,
the
src
attribute
of
an
embed
elements,
or
the
code
or
archive
attributes
of
an
applet
element.
object
or
an
embed
element.
It
is
not
required
that
the
consumer
of
the
element's
data
be
a
plugin
in
order
for
the
object-src
directive
to
be
enforced.
Data
for
any
object
,
embed
,
or
applet
element
must
match
the
allowed
object
sources
in
order
to
be
fetched.
This
is
true
even
when
the
element
data
is
semantically
equivalent
to
content
which
would
otherwise
be
restricted
by
one
of
the
other
directives
,
such
as
an
object
element
with
a
text/html
MIME
type.
Whenever
the
user
agent
would
load
a
plugin
without
an
associated
URI
(e.g.,
because
the
object
element
lacked
a
data
attribute),
if
the
protected
resource's
URI
does
not
match
the
allowed
object
sources
,
the
user
agent
must
not
load
the
plugin.
style-src
The
style-src
directive
restricts
which
styles
the
user
applies
to
the
protected
resource.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "style-src" directive-value = source-list
If
the
policy
contains
an
explicit
style-src
,
let
the
allowed
style
sources
be
the
result
of
parsing
the
directive's
value
as
a
source
list
.
Otherwise,
let
the
allowed
style
sources
be
the
default
sources
If
'unsafe-inline'
is
not
in
allowed
style
sources
:
style
element,
instead
the
user
agent
must
ignore
the
style.
style
attribute,
instead
the
user
agent
must
ignore
the
style.
Note:
These
restrictions
on
inline
do
not
prevent
the
user
agent
from
applying
style
from
an
external
stylesheet
(e.g.,
found
via
<link
rel="stylesheet">
).
The
user
agent
is
also
not
prevented
from
applying
style
from
Cascading
Style
Sheets
Object
Model
(CSSOM).
[
CSSOM
]
Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed style sources , the user agent must act as if it had received an empty HTTP 400 response :
href
attribute
of
a
link
element
with
a
rel
attribute
containing
the
token
stylesheet
or
when
processing
the
@import
directive
in
a
stylesheet.
Note:
The
style-src
directive
does
not
restrict
the
use
of
XSLT.
XSLT
is
restricted
by
the
script-src
directive
because
the
security
consequences
of
including
an
untrusted
XSLT
stylesheet
are
similar
to
those
incurred
by
including
an
untrusted
script.
img-src
The
img-src
directive
restricts
from
where
the
protected
resource
can
load
images.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "img-src" directive-value = source-list
If
the
policy
contains
an
explicit
img-src
,
let
the
allowed
image
sources
be
the
result
of
parsing
the
directive's
value
as
a
source
list
.
Otherwise,
let
the
allowed
image
sources
be
the
default
sources
Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed image sources , the user agent must act as if it had received an empty HTTP 400 response :
src
attribute
of
an
img
elements,
the
url()
or
image()
values
on
any
Cascading
Style
Sheets
(CSS)
property
that
is
capable
of
loading
an
image
[
CSS3-Images
],
or
the
href
attribute
of
a
link
element
with
an
image-related
rel
attribute,
such
as
icon
.
media-src
The
media-src
directive
restricts
from
where
the
protected
resource
can
load
video
and
audio.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "media-src" directive-value = source-list
If
the
policy
contains
an
explicit
media-src
,
let
the
allowed
media
sources
be
the
result
of
parsing
the
directive's
value
as
a
source
list
.
Otherwise,
let
the
allowed
media
sources
be
the
default
sources
Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed media sources , the user agent must act as if it had received an empty HTTP 400 response :
src
attribute
of
a
video
,
audio
,
source
,
or
track
elements.
frame-src
The
frame-src
directive
restricts
from
where
the
protected
resource
can
embed
frames.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "frame-src" directive-value = source-list
If
the
policy
contains
an
explicit
frame-src
,
let
the
allowed
frame
sources
be
the
result
of
parsing
the
directive's
value
as
a
source
list
.
Otherwise,
let
the
allowed
frame
sources
be
the
default
sources
Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed frame sources , the user agent must act as if it had received an empty HTTP 400 response :
iframe
or
a
frame
element.
font-src
The
font-src
directive
restricts
from
where
the
protected
resource
can
load
fonts.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "font-src" directive-value = source-list
If
the
policy
contains
an
explicit
font-src
,
let
the
allowed
font
sources
be
the
result
of
parsing
the
directive's
value
as
a
source
list
.
Otherwise,
let
the
allowed
font
sources
be
the
default
sources
Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed font sources , the user agent must act as if it had received an empty HTTP 400 response :
@font-face
Cascading
Style
Sheets
(CSS)
rule.
connect-src
The
connect-src
directive
restricts
which
URIs
the
protected
resource
can
load
using
script
interfaces.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "connect-src" directive-value = source-list
If
the
policy
contains
an
explicit
connect-src
,
let
the
allowed
connection
targets
be
the
result
of
parsing
the
directive's
value
as
a
source
list
.
Otherwise,
let
the
allowed
connection
targets
be
the
default
sources
Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed font sources , the user agent must act as if it had received an empty HTTP 400 response :
open()
method
of
an
XMLHttpRequest
object.
WebSocket
constructor
.
EventSource
constructor
.
sandbox
(Optional)
The
sandbox
directive
is
optional.
The
sandbox
directive
specifies
an
HTML
sandbox
policy
that
the
user
agent
applies
to
the
protected
resource.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "sandbox" directive-value = token *( 1*WSP token ) token = <token from RFC 2616>
When
enforcing
the
sandbox
directive,
a
user
agent
that
supports
the
sandbox
directive
must
parse
the
sandboxing
directive
using
the
directive-value
as
the
input
and
protected
resource's
forced
sandboxing
flag
set
as
the
output.
[
HTML5
]
report-uri
The
report-uri
directive
specifies
a
URI
to
which
the
user
agent
sends
reports
about
policy
violation.
The
syntax
for
the
name
and
value
of
the
directive
are
described
by
the
following
ABNF
grammar:
directive-name = "report-uri" directive-value = uri-reference *( 1*WSP uri-reference ) uri-reference = <URI-reference from RFC 3986>
Let
the
set
of
report
URIs
be
the
value
of
the
report-uri
directive,
each
resolved
relative
to
the
protected
resource's
URI.
To send a violation report , the user agent must use an algorithm equivalent to the following:
POST
,
with
a
Content-Type
header
field
of
application/json
with
an
entity
body
consisting
of
the
violation
report
.
The
user
agent
must
not
follow
redirects
when
fetching
this
resource.
(Note:
The
user
agent
ignores
the
fetched
resource.)
This section is non-normative.
This section provides some sample use cases and accompanying security policies.
Example 1: A server wishes to load resources only form its own origin:
Content-Security-Policy: default-src 'self'
Example 2: An auction site wishes to load images from any URI, plugin content from a list of trusted media providers (including a content distribution network), and scripts only from a server under its control hosting sanitized ECMAScript:
Content-Security-Policy: default-src 'self'; img-src *; object-src media1.example.com media2.example.com *.cdn.example.com; script-src trustedscripts.example.com
Example 3: Online banking site wishes to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests:
Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'
This
policy
allows
inline
content
(such
as
inline
script
elements),
use
of
eval
,
and
loading
resources
over
https
.
Note:
This
policy
does
not
provide
any
protection
from
cross-site
scripting
vulnerabilities.
Example 4: A social network wishes to ensure that all scripts are loaded from a specific path to prevent user-generated content from being interpreted as script:
Content-Security-Policy: default-src 'self'; script-src https://example.com/js/
Unfortunately,
this
use
case
is
not
supported
in
CSP
1.0.
The
user
agent
will
ignore
the
path
and
act
as
if
the
policy
contained
a
script-src
directive
with
value
https://example.com
.
A
future
version
of
CSP
might
begin
enforcing
these
path
restrictions,
however.
This section is non-normative.
This section contains an example violation report the user agent might sent to a server when the protected resource violations a sample policy.
In
the
following
example,
the
user
agent
rendered
a
representation
of
the
resource
http://example.org/page.html
with
the
following
CSP
policy:
default-src 'self'; report-uri http://example.org/csp-report.cgi
The
protected
resource
loaded
an
image
from
http://evil.example.com/image.png
,
violating
the
policy.
{ "csp-report": { "document-uri": "http://example.org/page.html", "referrer": "http://evil.example.com/haxor.html", "blocked-uri": "http://evil.example.com/image.png", "violated-directive": "default-src 'self'", "original-policy": "default-src 'self'; report-uri http://example.org/csp-report.cgi" } }
The
style-src
directive
restricts
the
locations
from
which
the
protected
resource
can
load
styles.
However,
if
the
user
agent
uses
a
lax
CSS
parsing
algorithm,
an
attacker
might
be
able
to
trick
the
user
agent
into
accepting
malicious
"style
sheets"
hosted
by
an
otherwise
trustworthy
origin.
These attacks are similar to the CSS cross-origin data leakage attack described by Chris Evans in 2009. User agents should defend against both attacks using the same mechanism: stricter CSS parsing rules for style sheets with improper MIME types.
The
violation
reporting
mechanism
in
this
document
has
been
designed
to
mitigate
the
risk
that
a
malicious
web
site
could
use
violation
reports
to
probe
the
behavior
of
other
servers.
For
example,
consider
a
malicious
web
site
that
white
lists
https://example.com
as
a
source
of
images.
If
the
malicious
site
attempts
to
load
https://example.com/login
as
an
image,
and
the
example.com
server
redirects
to
an
identity
provider
(e.g.,
idenityprovider.example.net
),
CSP
will
block
the
request.
If
violation
reports
contained
the
full
blocked
URL,
the
violation
report
might
contain
sensitive
information
contained
in
the
redirected
URI,
such
as
session
identifiers
or
purported
identities.
For
this
reason,
the
user
agent
includes
only
the
origin
of
the
blocked
URI.
The
Content-Security-Policy
header
is
an
end-to-end
header.
It
is
processed
and
enforced
at
the
client
and,
therefore,
should
not
be
modified
or
removed
by
proxies
or
other
intermediaries
not
in
the
same
administrative
domain
as
the
resource.
The
originating
administrative
domain
for
a
resource
might
wish
to
apply
a
Content-Security-Policy
header
outside
of
the
immediate
context
of
an
application.
For
example,
a
large
organization
might
have
many
resources
and
applications
managed
by
different
individuals
or
teams
but
all
subject
to
a
uniform
organizational
standard.
In
such
situations,
a
Content-Security-Policy
header
might
be
added
or
combined
with
an
existing
one
at
a
network-edge
security
gateway
device
or
web
application
firewall.
To
enforce
multiple
policies,
the
administrator
should
combine
the
policy
into
a
single
header.
An
administrator
might
wish
to
use
different
combination
algorithms
depending
on
his
or
her
intended
semantics.
One sensible policy combination algorithm is to start by allowing a default set of sources and then letting individual upstream resource owners expand the set of allowed sources by including additional origins. In this approach, the resultant policy is the union of all allowed origins in the input policies.
Another sensible policy combination algorithm is to intersect the given policies. This approach enforces that content comes from a certain whitelist of origins, for example, preventing developers from including third-party scripts or content in violation of organizational standards and practices. In this approach, the combination algorithm forms the combined policy by removing disallowed hosts from the policies supplied by upstream resource owners.
Interactions
between
the
default-src
and
other
directives
should
be
given
special
consideration
when
combining
policies.
If
none
of
the
policies
contains
a
default-src
directive,
adding
new
src
directives
results
in
a
more
restrictive
policy.
However,
if
one
or
more
of
the
input
policies
contain
a
default-src
directive,
adding
new
src
directives
might
result
in
a
less
restrictive
policy,
for
example,
if
the
more
specific
directive
contains
a
more
permissive
set
of
allowed
origins.
Using a more restrictive policy than the input policy authored by the resource owner might prevent the resource from rendering or operating as intended.
The permanent message header field registry (see [ RFC3864 ]) should be updated with the following registrations:
Header field name: Content-Security-Policy
Applicable protocol: http
Status: standard
Author/Change controller: W3C
Specification
document:
this
specification
(See
Content-Security-Policy
Header
Field
)
Header field name: Content-Security-Policy-Report-Only
Applicable protocol: http
Status: standard
Author/Change controller: W3C
Specification
document:
this
specification
(See
Content-Security-Policy-Report-Only
Header
Field
)