Security notes / website security notes

From Helpful
(Redirected from Same-origin policy)
Jump to navigation Jump to search

Security related stuff.

Linux - PAM notes · SELinux

Securing services

A little more practical

More techincal waffling

Message signing notes · Hashing notes ·
Auth - identity and auth notes
Encryption - Encryption notes · public key encryption notes · data-at-rest encryption ·pre-boot authentication · encrypted connections

Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted


Cross-Site Scripting (XSS) refers to a situation where malicious code ends up in otherwise trusted websites.

Generally to the end of someone making your browser do something you really don't want it to.

See also:

Things that help - while coding


Parse your data

Consider CSS

Things that help

Same-origin policy

Is assumed that resources mentioned on the website's initial page load are free to be loaded and executed and it wants, because if the page the server sends itself already contains exploits, then it's already too late anyway.

Much the same logic goes for things loaded from the same origin (specifically meaning the combination of protocol+host+port, because you can reasonably assume it's under the same control - or lack thereof).

(as a side effect, you ensure you are aware of everything under your own hostname. Shared hosting that shares the exact same hostname was always a bad idea)

As such, embedded images, stylesheets, scripts, iframes, audio and video is generally not restricted.

However, anything loaded from other hostnames elsewhere is suspect, particularly if it content that might involve execution.

As such,

fetching anything via XHR / Fetch
embedded fonts
WebGL textures
image loads via drawImage
...and more

...will be due to the same-origin policy, which means the browser will refuse to do this unless it is a request to the same hostname that the original page came from (hostname, not even domain it's in - it's useful to read the standard here to avoid confusion).

The SOP protects against exploits like some forms of cross-site scripting, and potential bugs in data-loading code that isn't happening in the browser (e.g. GPUs).

SOP also means you have to do extra work to mix data between different hosts even where you know it would be fine for them to trust each other, which is rather annoying when you e.g. want distinct host(name)s to spread load.

You have options like

just same-origin - too restrictive
disabling same-origin on the browser side. Not going to happen - it's manual work for each user, and too dangerous anyway.
subverting same-origin via a server-side script that fetches things for you, and/or inserting script tags
e.g. JSONP
because while that works, it's not always efficient, and some forms of it may be great resources for hackers (consider having open redirects, third-party subversion of same-origin, more)

See also:


This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

For context, read the same-origin policy bit above - that's what we're making an exception to.

CORS (Cross-Origin Resource Sharing) allows exceptions to the Same-origin policy, and alternative to the mentioned workarounds, by having the server advise the browser to allow a specific load.

If you use a CDN, then understanding and using CORS may make your life simpler.

While it is no worse than subversions of same-origin, and is relevant around XSS and such, it is not protection. If anything, it loosens security.


  • CORS does not protect against XSS per se. It can't be protection against injected "load executable things from bad server" style XSS, because that injection already was the bad thing. And any server can say "yes okay fine", so e.g.
if someone can inject code that does XHR/fetch, then CORS cannot save you
if you included a library from a less-than-trustable site, you did the bad thing
if someone steals a domain, good luck
and a few more details beyond that
  • Prevents use of / execution of data after a request is made, does not prevent making a request with a possible (side) effect in the first place does not prevent basic CSRF
  • Prevents use of / execution of fetched data, not the fetching of the data in the first place.
You could read CORS as 'the server may still send the data to the browser, along with the advice that should does not execute it'
All modern browsers choose to adhere to it, but it's technically still advisory' to the browser and can be bypassed via browser settings
  • is is absolutely not blanket XSS / CSRF protection
yet helps against some specific variants.

On the preflight thing

CORS considers that you could be doing things with custom headers, unusual HTTP methods, etc, for example web APIs and other protocols on top of HTTP. And that requests can have side effects, e.g. POSTs.

As such, it allows separation of the consent check (via OPTIONS), and the actual interaction (often a data fetch)

useful when the actual request might do a lot of work, or alter state (e.g. is POST), so useful for APIs and protocols built on HTTP
single-page XHR/fetch can often avoid preflight (...though CORS defines the cases, and not all uses will fit it)

So API and app developers may up front decide preflight is a better idea

CORS without preflight is simpler to implement

because only Origin and Access-Control-Allow-Origin are involved
the browser adds Origin (you can't even touch it via scripting, for obvious security reasons)
the server, if it agrees, sends back response header Access-Control-Allow-Origin where the value is either:
the Origin URL value it got in the request, or
*, if the resource is entirely public

Supporting CORS with preflight needs a few more headers, depending on case, probably at least

Access-Control-Allow-Methods (e.g. POST)
Access-Control-Allow-Headers (e.g. Origin, Content-Type)

While CORS's design considers the existence of auth, CORS doesn't handle authentication itself (also limiting the meaning of this authorization)


  • Some proxies refuse OPTIONS
  • Some VPNs refuse CORS
in which case JSONP may be the more compatible fix


This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Content-Security-Policy (CSP), roughly, is a server telling a browser (either in HTTP headers, or in HTML meta tags) what other places it considers safe to load+execute scripts from, and that a page is allowed to load from.

Such requirements can also be specified for media and images, which allows you to be explicitly more lenient about these.

This is mainly aimed at reducing reduce XSS issues when using CDNs, in that injected code cannot come from servers not explicitly known and allowed from the original page.

...though note that 'known' isn't the same as 'trusted', so it does not eliminite attack surface.


  • Same host (not subdomains)
Content-Security-Policy: default-src 'self'
  • Subdomains too:
Content-Security-Policy: default-src 'self' *
  • Specific host, and use HTTPS:
Content-Security-Policy: default-src 'self'
  • Images from anywhere, media from sister domain, scripts from specific own host
Content-Security-Policy: default-src 'self'; img-src *; media-src *; script-src


This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Tells a browser to stops loading when seeing reflected XSS attacks.

Seems targeted at a past versions of specific browsers -- those that didn't yet support standard CSP yet, but did specifically support this as a stopgap. You can assume specific browsers will never implement, because this was a non-standard, won't-be-standard thing.

It's still left in with "can't hurt to add it" reasons but it won't be doing much of anything on up-to-date clients.

Fetch metadata request header


Privacy concerns

Visitor fingerprinting

Cookie-like things

"Information you gave to the browser/server that it's storing with you, and sends back verbatim"

It can only store things you already had, and not be used to find out anything new. So it's not a security concern.

Yet it can be a privacy concern, for a few different reasons.

Primarily, many uses of a cookie are to identify when a specific browser re-visits a site.

There are perfectly good uses for this, like "do we stay logged into a site?" (or, say, that a shopping basket you collected while not logged in yet makes it to your account when you log in later), which is a feature a visiting user would want.

An example of a more dubious use is that ad sites historically could collect that a particular browser (so probably person and type of person) would visit the same set of sites, so could serve you ads based on people with similar interests. This will work without ever tying it to any particular person at any point. (this has become much harder to do today, due to stricter cookie policies)

The point of these two examples is that, as a transparent mechanism, good and bad uses happen equally silently. You can disable cookies, but that disables all uses.

Basic browser cookies
Not information theft

Cookies can only ever repeat back information verbatim.

As such, they store what a server, or browser script from a setver, already knew.

If that contains something you didn't want them to have, that is the issue, and not the fact that it is then stored in a cookie.

Cookies also only ever go back to the originating server. They cannot be used to send data to other serves (however, if there is a third party hosted on the same server, there is more care that cookie code must take).

Cookies store (text) data, not executable, so is not something that enables scripts, viruses, adware, or such to work.

Tracking cookies
Cookie overriding
Cookie theft
Flash cookies

Or, as Adobe calls them, Local Shared Objects.

HTML5 SessionStorage
HTML5 Database Storage
MSIE user data persistence
Google Gears


Denied due to GDPR?