Clearing houses

Injections (SQL and others)
Broken Authentication and Session Management
XSS (Cross Site Scripting)
Insecure Direct Object References
Sensitive Data Exposure
Security Misconfiguration
Missing Function Level Access Control
CSRF (Cross-Site Request Forgery)
Using Components with Known Vulnerabilities
Open Redirects / Unvalidated Redirects and Forwards
Mixed Content

Content Security Policy (CSP)


Consider using retire.js to check for vulnerable NPM packages.  Add this check 
to your Continous Integration setup.

Cookies are easier to steal and are hard to use in a multi-server setup.  Tokens 
solve both of those problems.  Tokens can also be used with a completely 
stateless server architecture.  Use a standard solution such as JWT-style 
bearer tokens.

If we want the user to stay logged in after they close our application window, 
we will need to store the token somehow on the client.  localStorage is a common 
option, but we need to consider the specific requirements of our application.  
We need to remember to remove the token upon logout, or have some expiration 
mechanism (expires the token if it has been more than X days).

Tokens stored in localStorage can be accessed by any JavaScript loaded from the 
same domain.  This becomes a problem if our application is vulnerable to XSS 

There are two routes toward securing localStorage further.  One is to encrypt 
the token before storing.  This step creates a hurdle for an attacker, but we 
now face the challenge of where to store the key.  There are a few options, and 
none of them is entirely satisfying.

Another approach is to take advantage of the fact that localStorage is domain 
specific to ensure that the token is written by a domain that we are certain is 
safe from XSS.  In this case, we need to figure out how to move the token 
between domains, which can be done using an iframe and postMessage().

When using JWT tokens, consider that the token carries a data payload that is 
signed but not encrypted.  If the content of that payload is sensitive, the 
server should encrypt it before sending it to the client.  A JWT token is 
encoded and looks encrypted but it is not.  It can be easily converted into a 
JSON object.

What are the trade-offs between session cookie and localStorage? can create a cookie on, and if create a cookie for, this cookie will be sent to the next time that the user visit If create a cookie on, the next time the that the user visit, the server thinks that the user is already authenticate, and if the user does not look closely enough, he may not realize that the account that he is accessing is not his own account, but some fake account, and he may store his sensitive information in this fake malicious account.

If the user log into, and the server create a cookie for, and the the user visits, that cookie will be sent to, and the evil crook on can see the cookie, he can then log into, and then use script to swap out the cookie, and now he would be able to access the innocent user's account, and steal sensitive information, change password, change sensitive information, or transfer money to another temporary online account, or use the money to pay for his purchases that are delivered to a vacant or mostly empty address that he can keep an eye on.

localStorage tokens are like origin cookies in that they are scoped to a particular origin. Only can read and set its own localStorage values; cannot interfere with tokens stored in's localStorage. Even better, storing tokens in localStorage make Meteor apps immune to CSRF attacks. An evil site simply cannot read a victim app's localStorage, so it cannot open an authenticated connection to the victim app.

When localStorage tokens are used to authenticate long-lived connections, we achieve very nice security properties. The tokens are explicitly read out by code that has the privileges to do so (no ambient authority!), and sent over the network once at the beginning of a long-lasting connection. They infrequently leave the browser, which means that there is less opportunity for an eavesdropper to steal them, or for an active attacker to perform a timing attack that relies on the secret token being sent over the network many thousands of times in a short period of time.

However, localStorage tokens are not a silver bullet. The primary downside is that this authentication mechanism is simply not as well-studied or battle-hardened as session cookies. CSRF attacks were not discovered until session cookies had been in use already for years; completely new attacks may yet be discovered that target modern apps that forgo session cookies in favor of other authentication mechanisms.

More concretely, cookies have some security features that we lack when we store tokens inlocalStorage, but it's possible that future versions of Meteor could achieve some of these security features while retaining the nice security properties of localStorage tokens, by using both cookies and localStorage tokens. One example is the httpOnly flag that makes cookies unreadable to JavaScript code, so that a cross-site scripting attack or malicious bookmarklet cannot steal sensitive cookies like session cookies. localStorage is of course accessible to JavaScript code, so a cross-site scripting hole on a Meteor app can leak the session token. We think this is an acceptable trade-off, and one we may be able to get around in the future with some clever tricks: for example, Meteor could require two tokens to authenticate a DDP connection: both a httpOnly cookie and a localStorage token.

What is session fixation?


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License