Security notes / website security notes

From Helpful
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)

For context, the loading/embedding of images, stylesheets, scripts, iframes, audio and video is generally not restricted.

However, things where execution might in some way be involved (e.g. XHR / Fetch, embedded fonts, WebGL textures, image loads via drawImage) are restricted via the same-origin policy, 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).

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.


  • is itself not XSS / CSRF protection
because any server can say "yes okay fine", so e.g.
if someone can inject code that does XHR, 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 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 technically still advisory' to the browser and can be bypassed via browser settings
  • note that it also applies to anything read/fetched by a script.
e.g. a player loading video will be blocked from content - that you could e.g. embed directly

On the preflight thing

CORS considers that you could be doing things with custom headers, unusual HTTP methods, etc, for example when implement APIs, build 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 data fetch

useful when the actual request might alter state (e.g. is POST), so useful for APIs and protocols built on HTTP
single-page XHR 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