Database

• [   ]   Use encryption for data identifying users and sensitive data like access tokens, email addresses or billing details if possible (this will restrict queries to exact match lookups).

• [   ]   If your database supports low cost encryption at rest (like AWS Aurora), then enable that to secure data on disk. Make sure all backups are stored encrypted as well.

• [   ]   Use minimal privilege for the database access user account. Don’t use the database root account and check for unused accounts and accounts with bad passwords.

• [   ]   Store and distribute secrets using a key store designed for the purpose. Don’t hard code in your applications and definitely don’t store in GitHub!. For CMS fans, don’t store your credentials in a file in the document directory.

• [   ]   Fully prevent SQL injection by only using SQL prepared statements. For example: if using NPM, don’t use npm-mysql, use npm-mysql2 which supports prepared statements.

Development

• [   ]   Ensure that all components of your software are scanned for vulnerabilities for every version pushed to production. This means O/S, libraries and packages. This should be automated into the CI-CD process.

• [   ]   Secure development systems with equal vigilance to what you use for production systems. Build the software from secured, isolated development systems.

Authentication

• [   ]   Ensure all passwords are hashed using appropriate crypto such as bcrypt. Never write your own crypto and correctly initialize crypto with good random data.

• [   ]   Use best-practices and proven components for login, forgot password and other password reset. Don’t invent your own — it is hard to get it right in all scenarios.

• [   ]   Implement simple but adequate password rules that encourage users to have long, random passwords.

• [   ]   Use multi-factor authentication for your logins to all your service providers.

• [   ]   Use a password manager such as 1Password for all service passwords and credentials. NEVER email passwords or credentials to team members and never checkin to the code repository.

• [   ]   Never, EVER have any undocumented and unpublicized means of access to the device including back-door accounts (like “field-service”).

Denial of Service Protection

• [   ]   Make sure that DOS attacks on your APIs won’t cripple your site. At a minimum, have rate limiters on your slower API paths and authentication related APIs like login and token generation routines. Consider CAPTCHA on front-end APIs to protect back-end services against DOS.

• [   ]   Enforce sanity limits on the size and structure of user submitted data and requests.

• [   ]   Consider using Distributed Denial of Service (DDOS) mitigation via a global caching proxy service like CloudFlare. This can be turned on if you suffer a DDOS attack and otherwise function as your DNS lookup.

Web Traffic

• [   ]   Use TLS for the entire site, not just login forms and responses. Never use TLS for just the login form. Transitionally, use the strict-transport-security header to force HTTPS on all requests.

• [   ]   Cookies must be httpOnly and secure and be scoped by path and domain.

• [   ]   Use CSP without allowing unsafe-* backdoors. It is a pain to configure, but worthwhile. Use CSP Subresource Integrity for CDN content.

• [   ]   Use X-Frame-Option, X-XSS-Protection headers in client responses. Use https://observatory.mozilla.org to score your site.

• [   ]   Use HSTS responses to force TLS only access. Redirect all HTTP request to HTTPS on the server as backup.

• [   ]   Use CSRF tokens in all forms and use the new SameSite Cookie response header which fixes CSRF once and for all newer browsers.

APIs

• [   ]   Ensure that no resources are enumerable in your public APIs.

• [   ]   Ensure that users are fully authenticated and authorized appropriately when using your APIs.

• [   ]   Use canary checks in APIs to detect illegal or abnormal requests that indicate attacks.

Validation and Encoding

• [   ]   Do client-side input validation for quick user feedback, but never trust it. Always validate and encode user input before displaying.

• [   ]   Validate every last bit of user input using white lists on the server. Never directly inject user content into responses. Never use untrusted user input in SQL statements or other server-side logic.

Cloud Configuration

• [   ]   Ensure all services have minimum ports open. While security through obscurity is no protection, using non-standard ports will make it a little bit harder for attackers.

• [   ]   Host backend database and services on private VPCs that are not visible on any public network. Be very careful when configuring AWS security groups and peering VPCs which can inadvertently make services visible to the public.

• [   ]   Isolate logical services in separate VPCs and peer VPCs to provide inter-service communication.

• [   ]   Ensure all services only accept data from a minimal set of IP addresses.

• [   ]   Restrict outgoing IP and port traffic to minimize APTs and “botification”.

• [   ]   Always use AWS IAM roles and not root credentials.

• [   ]   Use minimal access privilege for all ops and developer staff.

• [   ]   Regularly rotate passwords and access keys according to a schedule.

Infrastructure

• [   ]   Ensure you can do upgrades without downtime. Ensure you can quickly update software in a fully automated manner.

• [   ]   Create all infrastructure using a tool such as Terraform, and not via the cloud console. Infrastructure should be defined as “code” and be able to be recreated at the push of a button. Have zero tolerance for any resource created in the cloud by hand — Terraform can then audit your configuration.

• [   ]   Use centralized logging for all services. You should never need SSH to access or retrieve logs.

• [   ]   Don’t SSH into services except for one-off diagnosis. Using SSH regularly, typically means you have not automated an important task.

• [   ]   Don’t keep port 22 open on any AWS service groups on a permanent basis. If you must use SSH, only use public key authentication and not passwords.

• [   ]   Create immutable hosts instead of long-lived servers that you patch and upgrade. (See Immutable Infrastructure Can Be More Secure).

• [   ]   Use an Intrusion Detection System to minimize APTs.

Operation

• [   ]   Power off unused services and servers. The most secure server is one that is powered down. Schedule dev servers to be powered down after hours when not required.

Test

• [   ]   Audit your design and implementation.

• [   ]   Do penetration testing — hack yourself, but also have someone other than you pen testing as well.

Train

• [   ]   Train staff (especially senior staff) as to the dangers and techniques used in security social engineering.

Finally, have a plan

• [   ]   Have a threat model that describes what you are defending against. It should list and prioritize the possible threats and actors.

• [   ]   Have a practiced security incident plan. One day, you will need it.