|
10 | 10 | - [ ] Destory all active sessions on reset password (or offer to). |
11 | 11 | - [ ] Must have the `state` parameter in OAuth2 |
12 | 12 | - [ ] No open redirects after successful login or in any other intermediate redirects. |
13 | | -- [ ] While Signup/Login input, sanitize input for javascript://, data://, CRLF characters. |
| 13 | +- [ ] When parsing Signup/Login input, sanitize for javascript://, data://, CRLF characters. |
14 | 14 | - [ ] Set secure, httpOnly cookies. |
15 | 15 | - [ ] In Mobile `OTP` based mobile verification, do not send the OTP back in the response when `generate OTP` or `Resend OTP` API is called. |
16 | 16 | - [ ] 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. |
|
27 | 27 | - [ ] 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. |
28 | 28 | - [ ] `Profile photo upload` feature should sanitize all the `EXIF` tags also if not required. |
29 | 29 | - [ ] 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. |
30 | | -- [ ] JWT are awesome, use them if required for your single page app/APIs. |
| 30 | +- [ ] [JWT](https://jwt.io/) are awesome. Use them if required for your single page app/APIs. |
31 | 31 |
|
32 | 32 |
|
33 | 33 | ##### ANDRIOD / IOS APP |
|
63 | 63 | - [ ] Use a decent provisioning script to create VMs in the cloud. |
64 | 64 | - [ ] Check for machines with unwanted publicly `open ports`. |
65 | 65 | - [ ] Check for no/default passwords for `databases` especially MongoDB & Redis. BTW MongoDB sucks, avoid it. |
66 | | -- [ ] Use SSH to access your machines, do not setup a password. |
| 66 | +- [ ] Use SSH to access your machines; do not setup a password. |
67 | 67 | - [ ] Install updates timely to act upon zero day vulnerabilities like Heartbleed, Shellshock. |
68 | 68 | - [ ] Modify server config to use TLS 1.2 for HTTPS and disable all other schemes. (The tradeoff is good) |
69 | 69 | - [ ] 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. |
70 | 70 | - [ ] Be prepared for bad actors & DDOS - use [Cloudflare](https://www.cloudflare.com/ddos/) |
71 | | -- [ ] Setup monitoring for your systems and log stuff (use Newrelic or something like that) |
| 71 | +- [ ] Setup monitoring for your systems and log stuff (use [New Relic](https://newrelic.com/) or something like that) |
72 | 72 | - [ ] 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). |
73 | 73 |
|
74 | 74 | ##### PEOPLE |
|
77 | 77 | - [ ] Be polite to bug reporters. |
78 | 78 | - [ ] Have your code review done by a fellow developer from a secure coding perspective. (More eyes) |
79 | 79 | - [ ] 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. |
80 | | -- [ ] Setup Netflix Scumblr to hear about talks about your organization on social platforms and Google search. |
| 80 | +- [ ] Setup [Netflix's Scumblr](https://github.com/Netflix/Scumblr) to hear about talks about your organization on social platforms and Google search. |
0 commit comments