Security Checklist For Developers
Security Checklist For Developers
[Back to Contents](README.md)
- [ ] Store password hashes using `Bcrypt` (no salt necessary - `Bcrypt` does it for you).
- [ ] When parsing Signup/Login input, sanitize for javascript://, data://, CRLF characters.
- [ ] 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.
- [ ] Any resource access like, `my cart`, `my history` should check the logged in user's ownership of
the resource using session id.
- [ ] `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 compliant ](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.
- [ ] `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.
- [ ] On iOS, store sensitive information (authentication tokens, API keys, etc.) in the system keychain.
Do __not__ store this kind of information in the user defaults.
- [ ] `Add` [X-XSS-Protection](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#X-
XSS-Protection) header to mitigate XSS attacks.
- [ ] Use random CSRF tokens and expose business logic APIs as HTTP POST requests. Do not expose
CSRF tokens over HTTP for example in an initial 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.
- [ ] `Sanitize` all user inputs or any input parameters exposed to user to prevent
[XSS](https://en.wikipedia.org/wiki/Cross-site_scripting).
- [ ] Sanitize user input if using it directly for functionalities 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 concatenation ever, no matter how small the object is.
Use your language defined libraries or framework.
##### OPERATIONS
- [ ] If you are small and inexperienced, evaluate using AWS elasticbeanstalk or a PaaS to run your
code.
- [ ] Check for no/default passwords for `databases` especially MongoDB & Redis.
- [ ] Use SSH to access your machines; do not setup a password, use SSH key-based authentication
instead.
- [ ] 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 a hosting service that has DDOS mitigation.
- [ ] Set up monitoring for your systems, and log stuff (use [New Relic](https://newrelic.com/) 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 encrypted
now).
##### PEOPLE
- [ ] Set up an email (e.g. [email protected]) and a page for security researchers to report
vulnerabilities.
- [ ] Depending on what you are making, limit access to your user databases.
- [ ] 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.