Security issues happen for two reasons -
Developers who have just started and cannot really tell a difference between using MD5 or bcrypt. Developers who know stuff but forget/ignore them.
Our detailed explanations should help the first type while we hope our checklist helps the second one create more secure systems. This is by no means a comprehensive guide, it just covers stuff based on the most common issues we have discovered in the past.
Preview
- radio_button_unchecked* [Courtesy of Fallible Inc on Github](https://github.com/FallibleInc/security-guide-for-developers/blob/master/security-checklist.md)
- radio_button_uncheckedAUTHENTICATION SYSTEMS (Signup/Signin/2 Factor/Password reset)
- radio_button_uncheckedUse HTTPS everywhere.
- radio_button_uncheckedStore password hashes using Bcrypt (no salt necessary - Bcrypt does it for you).
- radio_button_uncheckedDestroy the session identifier after logout.
- radio_button_uncheckedDestroy all active sessions on reset password (or offer to).
- radio_button_uncheckedMust have the state parameter in OAuth2.
- radio_button_uncheckedNo open redirects after successful login or in any other intermediate redirects.
- radio_button_uncheckedWhen parsing Signup/Login input, sanitize for javascript://, data://, CRLF characters.
- radio_button_uncheckedSet secure, httpOnly cookies.
- radio_button_uncheckedIn Mobile OTP based mobile verification, do not send the OTP back in the response when generate OTP or Resend OTP API is called.
- radio_button_uncheckedLimit 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.
- radio_button_uncheckedCheck for randomness of reset password token in the emailed link or SMS.
- radio_button_uncheckedSet an expiration on the reset password token for a reasonable period.
- radio_button_uncheckedExpire the reset token after it has been successfully used.
- radio_button_uncheckedUSER DATA & AUTHORIZATION
- radio_button_uncheckedAny resource access like, my cart, my history should check the logged in user's ownership of the resource using session id.
- radio_button_uncheckedSerially 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.
- radio_button_uncheckedEdit email/phone number feature should be accompanied by a verification email to the owner of the account.
- radio_button_uncheckedAny 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.
- radio_button_uncheckedProfile photo upload feature should sanitize all the EXIF tags also if not required.
- radio_button_uncheckedFor user ids and other ids, use RFC compliant UUID instead of integers. You can find an implementation for this for your language on Github.
- radio_button_uncheckedJWT are awesome. Use them if required for your single page app/APIs.
- radio_button_uncheckedANDROID / IOS APP
- radio_button_uncheckedsalt from payment gateways should not be hardcoded.
- radio_button_uncheckedsecret / auth token from 3rd party SDK's should not be hardcoded.
- radio_button_uncheckedAPI calls intended to be done server to server should not be done from the app.
- radio_button_uncheckedIn Android, all the granted permissions should be carefully evaluated.
- radio_button_uncheckedOn iOS, store sensitive information (authentication tokens, API keys, etc.) in the system keychain. Do not store this kind of information in the user defaults.
- radio_button_uncheckedCertificate pinning is highly recommended.
- radio_button_uncheckedSECURITY HEADERS & CONFIGURATIONS
- radio_button_uncheckedAdd CSP header to mitigate XSS and data injection attacks. This is important.
- radio_button_uncheckedAdd CSRF header to prevent cross site request forgery. Also add SameSite attributes on cookies.
- radio_button_uncheckedAdd HSTS header to prevent SSL stripping attack.
- radio_button_uncheckedAdd your domain to the HSTS Preload List
- radio_button_uncheckedAdd X-Frame-Options to protect against Clickjacking.
- radio_button_uncheckedAdd X-XSS-Protection header to mitigate XSS attacks.
- radio_button_uncheckedUpdate DNS records to add SPF record to mitigate spam and phishing attacks.
- radio_button_uncheckedAdd subresource integrity checks if loading your JavaScript libraries from a third party CDN. For extra security, add the require-sri-for CSP-directive so you don't load resources that don't have an SRI sat.
- radio_button_uncheckedUse 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.
- radio_button_uncheckedDo 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.
- radio_button_uncheckedSANITIZATION OF INPUT
- radio_button_uncheckedSanitize all user inputs or any input parameters exposed to user to prevent XSS.
- radio_button_uncheckedAlways use parameterized queries to prevent SQL Injection.
- radio_button_uncheckedSanitize user input if using it directly for functionalities like CSV import.
- radio_button_uncheckedSanitize user input for special cases like robots.txt as profile names in case you are using a url pattern like coolcorp.io/username.
- radio_button_uncheckedDo not hand code or build JSON by string concatenation ever, no matter how small the object is. Use your language defined libraries or framework.
- radio_button_uncheckedSanitize inputs that take some sort of URLs to prevent SSRF.
- radio_button_uncheckedSanitize Outputs before displaying to users.
- radio_button_uncheckedOPERATIONS
- radio_button_uncheckedIf you are small and inexperienced, evaluate using AWS elasticbeanstalk or a PaaS to run your code.
- radio_button_uncheckedUse a decent provisioning script to create VMs in the cloud.
- radio_button_uncheckedCheck for machines with unwanted publicly open ports.
- radio_button_uncheckedCheck for no/default passwords for databases especially MongoDB & Redis.
- radio_button_uncheckedUse SSH to access your machines; do not setup a password, use SSH key-based authentication instead.
- radio_button_uncheckedInstall updates timely to act upon zero day vulnerabilities like Heartbleed, Shellshock.
- radio_button_uncheckedModify server config to use TLS 1.2 for HTTPS and disable all other schemes. (The tradeoff is good.)
- radio_button_uncheckedDo 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.
- radio_button_uncheckedBe prepared for bad actors & DDOS - use a hosting service that has DDOS mitigation.
- radio_button_uncheckedSet up monitoring for your systems, and log stuff (use New Relic or something like that).
- radio_button_uncheckedIf developing for enterprise customers, adhere to compliance requirements. If AWS S3, consider using the feature to encrypt data. If using AWS EC2, consider using the feature to use encrypted volumes (even boot volumes can be encrypted now).
- radio_button_uncheckedPEOPLE
- radio_button_uncheckedSet up an email (e.g. security@coolcorp.io) and a page for security researchers to report vulnerabilities.
- radio_button_uncheckedDepending on what you are making, limit access to your user databases.
- radio_button_uncheckedBe polite to bug reporters.
- radio_button_uncheckedHave your code review done by a fellow developer from a secure coding perspective. (More eyes)
- radio_button_uncheckedIn 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.
- radio_button_uncheckedSet up Netflix's Scumblr to hear about talks about your organization on social platforms and Google search.
No comments to display.