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 same-origin policy is a simple security model for web pages, that says that executable resources you link from a page must come from the same origin (origin here meaning protocol+host+port).

(Cross-Origin Resource Sharing) CORS allows exceptions to the same-origin policy, where the server of these external resources is explicitly okay with a specific request.

CORS is often preferable to

same-origin (too restrictive)
disabling same-origin on the browser side (too dangerous so isn't going to happen)
typical same-origin subversion-via-same-host-proxy-script (frequently vulnerable) (Also inefficient)

If you use a CDN, 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, CORS will not 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.
  • advisory' to the browser. All modern browsers choose to adhere to it.
  • note that it also applies to anything read by a script.
e.g. a player loading video will be blocked from content that you you can perfectly embed directly

On the preflight thing

  • preflight allows separation of the consent-check (via OPTIONS) and the actual content 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)

  • supporting 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 existance 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) hosts it considers sfe to load and 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 (note that known isn't the same as always 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

Technically: "client-side data persistence that can make its way back to a server"

Less technically: "Information you gave to the browser/server that it's storing with you"

So it's not a security concern in itself.

It can be a privacy concern. Indirectly, but still effectively: Many uses of a cookie are to identify when someone re-visits a site.

Good uses are often defined mostly in terms of usefulness: Does it serve a need? Does it support a feature the user might like? For example, do we stay logged into a site? Was the shopping basket stay remembered, even from before we logged in?

It is a transparent mechanism, so 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