Create security-checklist.md

Author: abhishek-anand

security-checklist.md

@@ -0,0 +1,77 @@
+### The Security Checklist 
+
+##### AUTHENTICATION SYSTEMS (Signup/Signin/2 Factor/Password reset) 
+- [ ] Use HTTPS everywhere.
+- [ ] Store password hashes using `Bcrypt` with a random `salt`.
+- [ ] Destroy the session identifier after `logout`.  
+- [ ] Destory all active sessions on reset password (or offer to).  
+- [ ] Must have the `state` parameter in OAuth2
+- [ ] No open redirects after successful login or in any other intermediate redirects.
+- [ ] While Signup/Login input, sanitize input for javascript://, data://, CRLF characters. 
+- [ ] Set secure, httpOnly cookies.
+- [ ] In Mobile `OTP` based mobile verification, do not send the OTP back in the response when `generate OTP` or `Resend OTP`  API is called.
+- [ ] Limit attempts to `Login`, `Verify OTP`, `Resend OTP` and `generate OTP` APIs for a particular user. Have an exponential backoff set or/and something like a captcha based challenge.
+- [ ] Check for randomness of reset password token in the emailed link or SMS 
+- [ ] Set an expiration on the reset password token for a reasonable period.
+- [ ] Expire the reset token after it has been successfully used.
+- [ ] Destroy the logged in user's session everywhere after successful reset of password. 
+
+
+##### USER DATA & AUTHORIZATION
+- [ ] Any resource access like, `my cart`, `my history` should check the logged in user's ownership of the resource using session id.
+- [ ] Serially iterable resource id should be avoided. Use `/me/orders` instead of `/user/37153/orders`. This acts as a sanity check in case you forgot to check for authorization token. 
+- [ ] `Edit email/phone number` feature should be accompanied by a verification email to the owner of the account. 
+- [ ] Any upload feature should sanitize the filename provided by the user. Also, for generally reasons apart from security, upload to something like S3 (and post-process using lambda) and not your own server capable of executing code.  
+- [ ] `Profile photo upload` feature should sanitize all the `EXIF` tags also if not required.
+- [ ] For user ids and other ids, use [RFC complaint ](http://www.ietf.org/rfc/rfc4122.txt) `UUID` instead of integers. You can find an implementation for this for your language on Github.  
+- [ ] JWT are awesome, use them if required for your single page app/APIs.
+
+
+##### ANDRIOD / IOS APP
+- [ ] `salt` from payment gateways should not be hardcoded.
+- [ ] `secret` / `auth token` from 3rd party SDK's should not be hardcoded.
+- [ ] API calls intended to be done `server to server` should not be done from the App.
+- [ ] In Android, all the granted  [permissions](https://developer.android.com/guide/topics/security/permissions.html) should be carefully evaluated.
+- [ ] [Certificate pinning](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) is highly recommended.
+
+
+##### SECURITY HEADERS & CONFIGURATIONS
+- [ ] `Add` [CSP](https://en.wikipedia.org/wiki/Content_Security_Policy) header to mitigate XSS and data injection attacks. This is important.
+- [ ] `Add` [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) header to prevent cross site request forgery.
+- [ ] `Add` [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) header to prevent SSL stripping attack.
+- [ ] `Add` [X-Frame-Options](https://en.wikipedia.org/wiki/Clickjacking#X-Frame-Options) to protect against Clickjacking.
+- [ ] `Add` [X-XSS-Protection](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#X-XSS-Protection) header to mitigate XSS attacks.
+- [ ] Update DNS records to add [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework) record to mitigate spam and phishing attacks.
+- [ ] Add [subresource integrity checks](https://en.wikipedia.org/wiki/Subresource_Integrity) if loading your JavaScript libraries from a third party CDN.
+- [ ] Use random CSRF tokens and expose buisness logic APIs as HTTP POST requests. Do not expose CSRF tokens over HTTP for example in a inital request upgrade phase.
+- [ ] Do not use critical data or tokens in GET request parameters. Exposure of server logs or a machine/stack processing them would expose user data in turn.
+
+##### SANITIZATION OF INPUT
+- [ ] `Sanitize` all user inputs or any input parameters exposed to user to prevent [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting)
+- [ ] `Sanitize` all user inputs or any input parameters exposed to user to prevent [SQL Injection](https://en.wikipedia.org/wiki/SQL_injection)
+- [ ] Sanitize user input if using it directly for functionalites like CSV import.
+- [ ] `Sanitize` user input for special cases like robots.txt as profile names in case you are using a url pattern like coolcorp.io/username. 
+- [ ] Do not hand code or build JSON by string concatentation ever, no matter how small the object is. Use your langauge defined libraries or framework.
+- [ ] Sanitize inputs that take some sort of URLs to prevent [SSRF](https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit#heading=h.t4tsk5ixehdd).
+- [ ] Sanitize Outputs before displaying to users.
+
+##### OPERATIONS
+- [ ] If you are small and inexperienced, evaluate using AWS elasticbeanstalk or a PaaS to run your code.
+- [ ] Use a decent provisioning script to create VMs in the cloud.
+- [ ] Check for machines with unwanted publicly `open ports`.
+- [ ] Check for no/default passwords for `databases` especially MongoDB & Redis. BTW MongoDB sucks, avoid it.
+- [ ] Use SSH to access your machines, do not setup a password.
+- [ ] Install updates timely to act upon zero day vulnerabilities like Heartbleed, Shellshock.
+- [ ] Modify server config to use TLS 1.2 for HTTPS and disable all other schemes. (The tradeoff is good)
+- [ ] Do not leave the DEBUG mode on. In some frameworks, DEBUG mode can give access full-fledged REPL or shells or expose critical data in error messages stacktraces.
+- [ ] Be prepared for bad actors & DDOS - use [Cloudflare](https://www.cloudflare.com/ddos/)
+- [ ] Setup monitoring for your systems and log stuff (use Newrelic or something like that)
+- [ ] If developing for enterprise customers, adhere to compliance requirements. If AWS S3, consider using the feature to [encrypt data](http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). If using AWS EC2, consider using the feature to use encrypted volumes (even boot volumes can be encypted now). 
+
+##### PEOPLE
+- [ ] Setup an email (e.g. security@coolcorp.io) and a page for security researchers to report vulnerabilities.
+- [ ] Depending on what you are making, limit access to your user databases.
+- [ ] Be polite to bug reporters.
+- [ ] Have your code review done by a fellow developer from a secure coding perspective. (More eyes)
+- [ ] In case of a hack or data breach, check previous logs for data access, ask people to change passwords. You might require an audit by external agencies depending on where you are incorporated.  
+- [ ] Setup Netflix Scumblr to hear about talks about your organization on social platforms and Google search.