This document discusses cross-origin resource sharing (CORS) and content security policy (CSP) as techniques to improve security in web applications. It begins by explaining the need for the same-origin policy and how CORS helps address limitations of SOP by allowing controlled cross-origin requests. It then discusses cross-site scripting (XSS) attacks and how CSP helps prevent XSS by allowing web applications to restrict resources that can be loaded or executed.

1. Same Origin Policy
Cross-Origin Resource Sharing
Content Security Policy
subbul@gmail.com

2. Agenda
•
•
•
•
Need for SOP
How CORS help SOP
What is XSS?
How CSP helps preventing XSS

3. Why Same Origin Policy ?
• What if your personal data you are entering in a “Bank” page
in Browser is accessible to another Page in the browser
Instance

4. What is Same Origin Policy
• This is a Browser Mechanism to allow trusted pages/scripts
• To Prevent HTML/JS Application from different window, domain accessing the
DOM, data of Application current domain or “Origin”
• Thanks to Same Origin Policy (SOP), Browser prevents loading or blocks request
for DOM access, execution of script from “Origin/Domain” other than “Self”
• More Details

5. What are allowed in SOP?
• SOP cannot prevent cross site content inclusions (like images, scripts, css
from different domain
• http://www.google.com/page1 can access http://www.google.com/page2
• http://www.google.com/page1 cannot access http://www.yahoo.com as
the two pages belong to different domain
• <script> is allowed by SOP [file:// ??]
• In a http://www.mypage.com page, you can include<script src=
http://api.google.com/googleplus >.
• Google API page scripts are executed in “Mypage” domain, HTML
Application, it will still have access to “Mypage” DOM elements. So, if the
“Google API scripts” are compromised, it will have bad effect on the
“MyPage” (Will take it to XSS- Cross Site Scripting)

6. What is not allowed in SOP?
• AJAX (XHR) from One domain to another
• XHR request from “MyPage.com” to “Google.com”
• Why it is not allowed?
– Using AJAX you can download a malicious JS code and could spoil the
current page information or could derive information from current
page and send it over maliciously to remote pages

7. How to circumvent SOP
•
•
•
•
Simple suggestion DO NOT USE ( unless it’s the End of the World)
Document.domain
PostMessage
JSONP
• Right Way
– CORS (Cross-Origin Resource Sharing)

8. Cross-Origin Resource Sharing
• CORS is to overcome SOP for XHR
• Allowing Cross Origin Request from Domain A to Domain B using XHR
• Introduction of new HTTP Headers (Origin) from Server to make Browser
decide to Allow Cross-Origin request or not
• Use Pre-flight (handshake) OPTIONS request for methods other than
POST/GET to know if the server supports, allow-origin for your request
More Detail

9. How CORS works?

10. CORS HTTP Request/Response Headers
HTTP Request/
ResponseHeader
Parameter
Description
Example
Access-Control-AllowOrigin:
<origin> | *
Specifying a particular
“domain” is allowed
or “*” all
Access-Control-AllowOrigin:
http://mozilla.com
Access-Control-AllowCredentials
True| false
Request for cookie
along with request
Access-ControlRequest-Method
GET,POST
Request for supported
HTTP methods
Access-Control-AllowHeaders
Content-Type|
Custom-Header
Preflight-request
headers

11. CORS Server/Browser Request /Response Flow
http://www.html5rocks.com/static/images/cors_server_flowchart.png

12. XSS (Cross Site Scripting)
• Finding Vulnerability of Web Pages and
injecting and injecting malicious client
side- script .
• Types
– Non-Persistent (server Echo’s back your
request)
– Adding malicious scripts in HTML Forms,
HTTP Query from web browser during a
search request. If the “String” is not
formatted/escaped, the injected script
will be executed back in client browser.
– E.g.,
• Phishing Attacks,
• URL Shortens (bit.ly ) taking to
legitimate page and injecting their
“script” along with it

13. XSS (Cross Site Scripting)
– Persistent (Server stores the data
and script)
– Storing user provided “string” as is
without escaping the HTML, JS code
in Webserver and serving later to all
users will cause the malicious script
to execute on client browser
– Message Boards, which include Plain
Text and Scripts, later when another
user reloads the Message Board, the
malicious code executes and steals
user data
– Defacing web
servers, cookie/session stealing

14. Examples
• http://www.insecurelabs.org/Task/Rule1
• http://www.insecurelabs.org
• https://www.owasp.org/index.php/Testing_for_Reflected_Cros
s_site_scripting_(OWASP-DV-001)

15. How to Prevent XSS
•
•
•
•
•
Validation/Sanitization of ALL user inputs in a page
No inline please, keep it safe in a dedicated JS
Secure all input path, query string, file path etc
Don’t keep untrusted data in your HTML, JS
This is one of the reason, you find forms in organization preventing
<, > etc 
• https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Pre
vention_Cheat_Sheet
• And of course CSP (Content Security Policy)

16. Content Security Policy (CSP)
• It’s a policy how Browser/UserAgent adhere to as a directive from
HTTP Server in order to display, execute scripts
• New HTTP Headers introduced to enable CSP
• Content-Security-Policy: script-src 'self'
Trusted Source
https://abc.MyWebpage.com
Resource
Trusted Source

17. Content Security Policy
• If a malicious code is injected through XSS (added <script src=“hackedsite.com”>), browser
will detect and prevent
• More XSS prevention by
• 'unsafe-inline' prevents inline JavaScript and CSS
• 'unsafe-eval' prevents text-to-JavaScript mechanisms like eval
• Default-src “none” (Shut down any other script, img, media load beyond my own)
• Other resources which can be controlled by CSP are font-src,img-src etc
–
–
–
–
http://www.html5rocks.com/en/tutorials/security/content-security-policy/
http://erlend.oftedal.no/blog/csp/readiness/
http://people.mozilla.org/~bsterne/content-security-policy/details.html
https://wiki.mozilla.org/index.php?title=Security/CSP/Spec&oldid=133465

18. Thank You