Security

http://www.owasp.org/
http://www.sitepoint.com/passwordless-authentication-works
https://www.sitepoint.com/you-dont-know-jacks/
https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards
https://www.dwheeler.com/secure-programs/
https://medium.com/@mattholt/retiring-the-green-padlock-149010086e6d

OpenID
Articles
Tools
Clearing houses

Introduction
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
Clickjacking
Mixed Content

Content Security Policy (CSP)
Miscellaneous

https://www.owasp.org/index.php/Top_10_2013-Top_10
https://www.owasp.org/index.php/Cheat_Sheets
https://www.owasp.org/index.php/OWASP_Guide_Project
https://www.owasp.org/index.php/ASVS
https://www.owasp.org/index.php/ESAPI
https://www.owasp.org/index.php/SAMM
https://www.owasp.org/index.php/WebGoat

https://www.owasp.org/index.php/Code_Review_Guide

https://www.owasp.org/index.php/OWASP_Guide_Project
https://www.owasp.org/index.php/OWASP_Testing_Project
https://www.owasp.org/index.php/Category:OWASP_Testing_Project
https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
https://www.owasp.org/index.php/Category:OWASP_Education_Project
https://www.owasp.org/index.php/Category:Software_Assurance_Maturity_Model
https://www.owasp.org/index.php/OWASP_Secure_Software_Contract_Annex
https://www.owasp.org/index.php/OWASP_Education_Presentation
https://www.owasp.org/index.php/Category:OWASP_Live_CD_Project
https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
https://www.owasp.org/index.php/Category:OWASP_AppSec_Conference
https://www.owasp.org/index.php/Category:OWASP_Code_Crawler
https://www.owasp.org/index.php/Category:OWASP_Orizon_Project
https://www.owasp.org/index.php/OWASP_O2_Platform

https://www.owasp.org/index.php/Projects
http://stores.lulu.com/owasp
http://findbugs.sourceforge.net/index.html
http://h3xstream.github.com/find-sec-bugs/

https://www.owasp.org/index.php/XXE
http://cwe.mitre.org/data/definitions/77.html
http://cwe.mitre.org/data/definitions/89.html
https://www.owasp.org/index.php/Authentication_Cheat_Sheet
https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
https://www.owasp.org/index.php/Testing_for_authentication
http://cwe.mitre.org/data/definitions/287.html
http://cwe.mitre.org/data/definitions/384.html

OAuth
OpenId
SAML
http://sforce.co/2gBAlPd

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 
attacks.

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?

appearInnocentButEvil.example.com can create a cookie on www.example.com, and if www.example.com create a cookie for example.com, this cookie will be sent to appearInnocentButEvil.example.com the next time that the user visit appearInnocentButEvil.example.com. If appearInnocentButEvil.example.com create a cookie on www.example.com, the next time the that the user visit www.example.com, 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 www.example.com, and the server create a cookie for example.com, and the the user visits appearInnocentButEvil.example.com, that cookie will be sent to appearInnocentButEvil.example.com, and the evil crook on appearInnocentButEvil.example.com can see the cookie, he can then log into www.example.com, 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 www.meteor.com can read and set its own localStorage values; evil.meteor.com cannot interfere with tokens stored in www.meteor.com'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?

I NEED TO READ UP ON THIS

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