Content Security Policy (CSP) | What is the difference between CORS and CSP?

#Security #CORS #CSP
CORS is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served.

A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos but the cross-domain Ajax requests are forbidden by default by the same-origin security policy.

The CORS is the preferred mechanism to enable the cross-domain AJAX requests by target resource to return a special HTTP response headers that indicate that cross-domain AJAX requests are allowed.

Some of the old browsers won't support the CORS headers in that case JSON-P is the trick to load the cross-domain resources.

CORS specification is very useful to access the cross-origin resources through AJax without compromising the security policy, the access can be enabled only for the trusted partners

Video - @dnEA

CSP stands for Content Security Policy Is a W3C specification offering the possibility to instruct the client browser from which location and/or which type of resources are allowed to be loaded. To define a loading behavior, the CSP specification uses “directive” where a directive defines a loading behavior for a target resource type.This helps to protect against cross-site scripting attacks (XSS), clickjacking, and other code injection attacks that rely on executing malicious content in the context of a trusted web page.

The Same Origin policy block a website from accessing data outside its own origin but malicious hackers use cross-site scripting (XSS) attacks to trick websites trusted by the user into delivering malicious code. . Without additional safety measures, the browser executes all code from a trusted origin and can’t tell which code is legitimate, so any injected malicious code is executed as well.

Content Security Policy (CSP) – a standardized set of directives that tells the browser what content sources can be trusted and which should be blocked. Using carefully defined policies, you can restrict browser content to eliminate many common injection vectors and significantly reduce the risk of XSS attacks.

script-src: Define which scripts the protected resource can execute
object-src: Define from where the protected resource can load plugins
style-src: Define which styles (CSS) the user applies to the protected resource
img-src: Define from where the protected resource can load images
media-src: Define from where the protected resource can load video and audio
frame-src: Define from where the protected resource can embed frames
frame-ancestors: Defines valid sources for embedding the resource using frame iframe object embed applet. Setting this directive to 'none' should be roughly equivalent to X-Frame-Options: DENY
font-src: Define from where the protected resource can load fonts
connect-src: Define which URIs the protected resource can load using script interfaces
form-action: Define which URIs can be used as the action of HTML form elements
Sandbox: Specifies an HTML sandbox policy that the user agent applies to the protected resource
plugin-types: Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded
report-uri: Specifies a URI to which the user agent sends reports about a policy violation
default-src: Define loading policy for all resources type in case of a resource type dedicated directive is not defined 

Directives can be specified as an HTTP response headers or as HTML meta tags. By using suitable CSP directives in HTTP response headers, you can selectively specify which data sources should be permitted in your web application.

The HTTP Content-Security-Policy-Report-Only response header allows web developers to experiment with policies by monitoring (but not enforcing) their effects. These violation reports consist of JSON documents sent via an HTTP POST request to the specified URI.

* - Wildcard, allows any URL
'none' - Prevents loading resources from any source.
'unsafe-inline' - Inline Scripts are Blocked by Default with Content Security Policy, Allows use of inline source elements such as style attribute, onclick, or script tag bodies, it disables all the defenses against inline scripts and XSS so not recommended

If you absolutely need to allow inline code without enabling unsafe-inline. To whitelist a specific piece of code, you can use either a nonce (unique one-time identifier) for a script tag or use a cryptographic hash for the code itself. You can then specify the nonce or hash in your script-src directive to allow that piece of inline code.

Sometimes the use of a hash is unwanted or impractical because the script might have dynamic data, causing the hash to change too. The alternative to this is the use of a nonce. A nonce is a generated random string that allows you to whitelist a complete code block regardless of its content.

'unsafe-eval' - Allows unsafe dynamic code evaluation such as JavaScript eval().

Видео Content Security Policy (CSP) | What is the difference between CORS and CSP? канала Tech Forum