Security notes / website security notes

From Helpful
Revision as of 16:12, 10 July 2021 by Helpful (Talk | contribs)

Jump to: navigation, search
Security related stuff.





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

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

See also:

Things that help - while coding


Parse your data

Consider CSS

Standards that help


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

The idea is roughly that initial page loads can do what it wants, but anything that is external and/or executed later needs to be thought about.

It's both about what you are fetching, and when.

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

But things where execution might in some way be involved (e.g. fetching anything via XHR / Fetch, image loads via drawImage embedded fonts, WebGL textures) are restricted via the same-origin policy (SOP), a basic security model that says that these resources must come from the same origin.

Origin here meaning protocol+host+port (because that implies the same web server or at least reverse proxy).

CORS (Cross-Origin Resource Sharing) allows exceptions to that same-origin policy, by having the server end be explicitly okay with a specific request.

In practical terms, CORS is often preferable to

just same-origin (too restrictive if you want e.g. distinct hosts to spread the network load)
disabling same-origin on the browser side (too dangerous, manual work for each user, so isn't going to happen)
subversion same-origin via a server-side script that fetches things for you
because while that works, it's not very efficient, and done wrong it is both a great resource for hackers (open redirects, third-party subversion of same-origin, more)

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


  • The idea behind SOP is that you have to do some work to mix data between different domains, in certain directions
This helps protect against some cases of XSS, but not others
it e.g. often doesn't help if code was injected already
it doesn't prevent giving you executable things - because it's the server, not the page, that says it's okay to execute it.
  • It's not protection against injected "load executable things from here" style XSS, because that injection is already 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 fetched data, not making a request with an effect in the first place
so does not prevent basic CSRF
  • Prevents use of / execution of fetched data, not the fetching of the data in the first place.
You should assume the server sends the data to the browser, along with the advice that it 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
but helps against specific variants.

On the preflight thing

CORS considers that you could be doing things with custom headers, unusual HTTP methods, etc, for example REST 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
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
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)


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Content-Security-Policy (CSP), roughly, is a server telling a browser what other places it considers safe to load+execute scripts from.

It also extends to media and images so that you can have more lenient rules for them.

This mainly helps reduce XSS issues when using CDNs, in that injected code cannot come from unknown servers (though note that 'known' isn't the same as 'trusted').


  • 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

Privacy concerns

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 only ever repeat back information (verbatim) that a remote server (or browser script originating from that server) put there. They can never be used to send any other data from your computer, they cannot be used to send data to third parties.

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