Web Application Security
CS4013
Same Origin Policy
What is an origin?
❖ In web applications, an origin is a fundamental concept in browser security that
defines where a web request or document comes from.
❖ An origin consists of three components:
Component Example Meaning
Scheme http, https The protocol used
Hostname [Link] The domain name
Port 80, 443 The network port (default is 80 for
http, 443 for https)
What is an origin?
Examples of origins:
URL Origin
[Link] [Link]
[Link] [Link]
[Link] [Link]
[Link] [Link]
❖ Even slight differences make the origins different.
❖ Same origin: Can share data, cookies, DOM, and make requests.
[Link]
[Link]
❖ Different origin: Cannot access each other’s content due to SOP.
[Link]
[Link]
❖ Thus, "Same origin" means same protocol, same domain, and same port.
Same Origin Policy
❖ Browsers enforce the Same-Origin Policy to isolate content between origins. This is
to prevent malicious pages from:
❖ Reading your private data on another website.
❖ Performing unauthorized actions on your behalf.
❖ Embedding content in hidden iframes and interacting with it.
❖ The same-origin policy is a critical security mechanism that restricts how a
document or script loaded by one origin can interact with a resource from another
origin.
❖ It helps isolate potentially malicious documents, reducing possible attack vectors.
❖ For example, it prevents a malicious website on the Internet from running JS in a
browser to read data from a third-party webmail service (which the user is signed
into) or a company intranet (which is protected from direct access by the attacker by
not having a public IP address) and relaying that data to the attacker.
Same Origin Policy
❖ The following table gives examples of origin comparisons with the
URL [Link]
URL Outcome Reason
[Link] Same origin Only the path differs
[Link]
Same origin Only the path differs
.html
[Link] Failure Different protocol
Different port (http:// is port
[Link] Failure
80 by default)
[Link] Failure Different host
Inherited origins
❖ Inherited origins refer to situations where a browser assigns the same origin to a
new document or script as the document or script that created it — even if the new
document has a special or empty URL.
❖ This is important in the context of the Same-Origin Policy, which controls what
one web page can access on another.
❖ Some special URLs do not have their own origin, so the browser assigns them an
inherited origin based on the context that created them.
❖ Some common cases are:
URL type Inherits origin from
about:blank The page or script that opened it
javascript: The page where the script was written
Iframe srcdoc The parent page containing the iframe
Inherited origins
❖ Example: about:blank window
let win = [Link]("about:blank");
[Link]("<script>alert([Link])</script>");
❖ The new window has the URL about:blank.
❖ It doesn't have its own origin.
❖ So it inherits the origin of the script that created it. This allows your script to
read/write content inside the popup (same-origin access).
❖ Some examples of non-inherited origins are:
URL type Gets its own origin?
[Link] Yes: Derived from the URL
data: Yes: Opaque origin (completely isolated)
file:// Yes, treated with strict policies
File origins
❖ File origins:
❖ The file:// scheme is used when a web page is opened directly from your local
file system — not from a web server. For example:
[Link]
❖ This URL loads the file locally from your computer, without using HTTP or
HTTPS.
❖ Unlike [Link] which has a well-defined origin (scheme + host +
port), file:// has no host component.
❖ So browsers treat the origin of file:// URLs differently:
Browser Behaviour with file:// origin
Chrome Every file:// URL has a unique origin — no cross-file access
Firefox All file:// files share the same origin — more permissive
Edge Follows Chrome’s strict origin separation
❖ This means that behaviour varies between browsers. Most modern browsers tend
toward restricting file access for security.
File origins
❖ Modern browsers usually treat the origin of files loaded using the [Link] schema
as opaque origins. What this means is that if a file includes other files from the same
folder (say), they are not assumed to come from the same origin, and may
trigger CORS errors.
❖ Why restrict file:// origins?
Security risk: If a local HTML file could access other local files (like
[Link] it could leak sensitive data if run with malicious
intent. So, most browsers restrict access to:
❖ Other local files
❖ Cookies
❖ XMLHttpRequest / fetch calls to other file:// URLs
Action Allowed Notes
Accessing same file Yes Works normally
Accessing sibling file Usually blocked in Security sandbox
Chrome
Making fetch() to another Often blocked Considered cross-origin
local file
Changing origin
❖ In web security, “changing origin” refers to how an origin, defined as
<scheme>://<host>:<port>
can change due to browser actions or developer choices — and this impacts access
control, cookies, and JavaScript permissions.
❖ It occurs when:
❖ The page navigates to another origin
❖ A script opens a new window or iframe pointing to a different origin
❖ A resource is fetched from another domain
❖ A sandboxed iframe or blob/data URL is used
Cross Origin Resource Sharing
❖ CORS is a security mechanism implemented by web browsers that allows or
blocks requests made from one origin to a different origin.
❖ This becomes relevant when JavaScript in a webpage tries to make an HTTP request
(e.g., fetch() or XMLHttpRequest) to a domain other than the one that served the
webpage.
❖ Due to SOP, a web page can only access resources (e.g., APIs, DOMs) from the
same origin.
❖ But modern applications often need to access APIs from different domains (e.g.,
[Link] calling [Link]).
❖ That’s where CORS comes in — it tells the browser whether it’s okay to share data
across origins.
Cross Origin Resource Sharing
❖ When your browser tries to access another origin’s resource, it performs a CORS
check:
❖ Example of Cross origin Request:
❖ A web-app hosted on [Link] wants to fetch() data from
[Link]
❖ In the CORS flow, first the browser sends a request with an Origin header:
GET /data HTTP/1.1
Origin: [Link]
❖ Server checks the origin and responds with headers like:
Access-Control-Allow-Origin: [Link]
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type
❖ If allowed: the browser allows access, otherwise, the browser blocks access and
throws a CORS error.
Cross Origin Resource Sharing
When a web browser makes a cross-origin HTTP request, it determines whether the
request is safe and simple enough to proceed directly, or if it needs to ask permission
first by making a preflight request.
Simple Requests: A Simple Request is a type of CORS request that does not trigger a
preflight request.
❖ Allowed Methods: GET, HEAD, POST.
❖ Safe headers (e.g., Content-Type: application/x-www-form-urlencoded).
❖ No custom headers.
❖ No credentials, by default.
Preflighted Requests: A Preflight Request is an automatic request the browser sends
before the actual request, to ask the server if it's okay to send the real request. It is
triggered when:
❖ Uses method other than GET, HEAD, POST (like PUT, DELETE, PATCH)
❖ Uses custom headers.
❖ Requests credentials.
Cross Origin Resource Sharing
❖ Key CORS response headers:
❖ Access-Control-Allow-Origin: specifies which origins are allowed.
❖ Access-Control-Allow-Methods: allowed HTTP methods
❖ Access-Control-Allow-Headers: allowed custom headers
❖ Access-Control-Allow-Credentials: allow cookies
❖ How pre-flight request works:
❖ Browser sends the pre-flight request.
❖ Server responds with CORS header indicating:
❖ Allowed origins.
❖ Allowed headers.
❖ Allowed methods.
❖ If the preflight response is acceptable, the actual request is sent.
Cross Origin Resource Sharing
❖ Common CORS errors:
❖ No 'Access-Control-Allow-Origin' header → request blocked
❖ CORS policy: Preflight request did not succeed
❖ Disallowed method or header → CORS failure
❖ Credentialed request without proper server permission
❖ Summary on CORS:
❖ CORS is a browser-based security feature.
❖ Server controls access via response headers.
❖ Browser enforces CORS rules.
❖ Important for modern APIs and secure frontend/backend integration.
Cross origin network access
The same-origin policy controls interactions between two different origins, such as
when you use fetch() or an <img> element. These interactions are typically placed into
three categories:
❖ Cross-origin writes are typically allowed. Examples are links, redirects, and
form submissions. Some HTTP requests require preflight.
❖ Cross-origin embedding is typically allowed. (Examples are listed below.)
❖ Cross-origin reads are typically disallowed, but read access is often leaked by
embedding. For example, you can read the dimensions of an embedded image,
the actions of an embedded script, or the availability of an embedded resource.
How to allow cross-origin access?
❖ Use CORS to allow cross-origin access. CORS is a part of HTTP that lets
servers specify any other hosts from which a browser should permit loading of
content.
Cross origin network access
How to block cross-origin access?
❖ To prevent cross-origin writes, check an unguessable token in the request —
known as a Cross-Site Request Forgery (CSRF) token. You must prevent cross-
origin reads of pages that require this token.
❖ To prevent cross-origin reads of a resource, ensure that it is not embeddable. It is
often necessary to prevent embedding because embedding a resource always
leaks some information about it.
❖ To prevent cross-origin embeds, ensure that your resource cannot be interpreted
as one of the embeddable formats listed above. Browsers may not respect
the Content-Type header. For example, if you point a <script> tag at an HTML
document, the browser will try to parse the HTML as JavaScript. When your
resource is not an entry point to your site, you can also use a CSRF token to
prevent embedding.
Cross origin script API access
Cross origin script API access:
JavaScript APIs like [Link], [Link], [Link],
and [Link] allow documents to directly reference each other. When two
documents do not have the same origin, these references provide very limited
access to Window and Location objects.
Cross origin data storage access:
Access to data stored in the browser such as Web Storage and IndexedDB are
separated by origin. Each origin gets its own separate storage, and JavaScript in
one origin cannot read from or write to the storage belonging to another origin.
Cookies use a separate definition of origins. A page can set a cookie for its own
domain or any parent domain, as long as the parent domain is not a public suffix.
Firefox and Chrome use the Public Suffix List to determine if a domain is a public
suffix. When you set a cookie, you can limit its availability using
the Domain, Path, Secure, and HttpOnly flags. When you read a cookie, you cannot
see from where it was set. Even if you use only secure https connections, any
cookie you see may have been set using an insecure connection.
