Security Note for Web Developers

Developing secure and reliable cloud-based web applications is no easy task. Even - very difficult. If you think that this is not so, then either you are a representative of a higher life form unknown to science, or you are waiting for a hefty roasted rooster.

If you are inspired by the ideas of creating a minimum viable product and are confident that you can develop something useful and safe in a month, think twice before releasing such a “product”, but rather, just a prototype.



After you review the following checklist of the tasks that you need to solve to ensure the security of your web project, you will probably see for yourself that a lot of what it contains is not taken into account in your development. What to do? At a minimum, be honest with potential users and let them know that your project is still under development, that you suggest that you familiarize yourself with the prototype, which has not yet implemented a complete security system.

Database

• If possible, use encryption to store information that identifies the user and to store confidential data, such as access tokens, email addresses or payment details (this approach, in particular, will limit database queries to the search level by exact match).
  
  
• If your DBMS supports cost-effective encryption of stored data, enable it to protect the information on the disks. In addition, check that all database backups are also encrypted.
  
  
• Use user accounts with minimal privileges to access databases. Do not use a superuser account and check the system for unused accounts and accounts with too weak passwords.
  
  
• Store and transfer account data, system access tokens and other secret information using a key store designed for such work scenarios. Do not store such data by hard-coded them in application code.
  
  
• Protect your system against attacks by SQL injection using only prepared SQL queries. For example, if your project is designed for Node.js, do not use the mysql nmp library, refer to the mysql2 library , which supports prepared queries.
  

Development

• Ensure that system components are checked for vulnerabilities before each release. We are talking about all the libraries, packages, and the working environment. Ideally, checks should be automated as part of the CI-CD process .
  
  
• Ensure the security of developers' computers by treating this issue with the same care you take with respect to the security of production servers. Development should be carried out on protected, isolated from potentially dangerous external environment machines.
  

Authentication

• Make sure that all passwords are hashed using a suitable cryptographic algorithm like bcrypt . Do not use self-written hashing functions; correctly initialize the used cryptosystems using high-quality random data.
  
  
• Use time-tested, well-proven components to organize a login, restore a forgotten password and reset your password. Do not reinvent the wheel. The fact is that with independent development it will be very difficult for you to ensure the correct operation of such mechanisms in all possible scenarios.
  
  
• Implement simple but non-threatening password requirements that encourage users to create long passwords consisting of random character sets.
  
  
• Use, for all service providers, multi-factor authentication.
  

DOS attack protection

• Make sure that DOS attacks on your API will not affect the site’s performance. At a minimum, enforce request frequency limits in the slowest API paths and in those parts of the project that are associated with authentication. For example, we can talk about login modules and subsystems for creating access tokens. Consider using CAPTCHA in those parts of the project that are accessible from the outside world to protect server subsystems from DOS attacks.
  
  
• Set robust restrictions on the size and structure of the data that users can send to the system, as well as on the queries they perform.
  
  
• Consider using the system to mitigate the effects of distributed DOS attacks, for example, using a global caching proxy service like CloudFlare . During the attack, this will help your project survive, and in normal times will reduce the load on the server and speed up the loading of the site.
  

Web traffic

• Use TLS for the entire site, not just to protect the authorization system. Never use TLS only to protect the authorization form. In the transition period, use the strict-transport-security HTTP header to enforce the use of the HTTPS protocol.
  
  
• Cookies must have the httpOnly attribute, they must be protected, path and domain parameters must be present among their attributes.
  
  
• Use the Content Security Policy ( CSP ) without giving unsafe-inline and unsafe-eval permissions. This policy is not easy to set up, but it is worth the effort and time. Use the Subresource Integrity engine for CDN content.
  
  
• Use the X-Frame-Option and X-XSS-Protection HTTP headers in client responses.
  
  
• Use the HSTS mechanism to provide access to the system using only TLS. Do not trust client systems, ensure the use of HTTPS on the server side.
  
  
• Use CSRF tokens in all forms, use the new SameSite cookie attribute to protect against CSRF attacks. It is supported by modern versions of browsers.
  

API

• Verify that there are no resources in the public API that can be discovered by brute force.
  
  
• Users must be fully authenticated and properly authorized before they can use the API.
  

Validation and data conversion

• Check, on the client side, the data entered by users. This will allow them to quickly respond to their actions. However, never trust this check. Always check and convert to the format you need what the user entered before displaying on the pages of the site.
  
  
• Check everything that comes from the user using white lists on the server. Never embed unencoded user input into HTTP requests and responses. Under no circumstances should you use potentially dangerous data entered by the user in SQL queries or in other server logic.
  

Cloud settings

• Verify that all cloud services have a minimum number of ports open. Although securing through information hiding is not protection, using non-standard ports will complicate the lives of those who try to attack your system.
  
  
• Keep databases and services in virtual private clouds (VPS, Virtual Private Cloud) to which there is no access from the outside. Be very careful when configuring AWS security groups and setting peering between VPCs, as errors can cause internal services to be visible from the outside.
  
  
• Isolate logical services in different VPCs and configure peering between them for inter-service communication.
  
  
• Make sure that all services only accept data from the minimum required set of IP addresses.
  
  
• Limit outgoing traffic by IP addresses and ports to minimize the possibility of targeted cyber attacks and bot attacks.
  
  
• Always use AWS IAM roles, not the superuser account.
  
  
• Use the minimum access privileges for those involved in system maintenance and for developers.
  
  
• Regularly, on a schedule, rotate passwords and passwords.
  

Infrastructure

• Make sure you can perform project updates without downtime. Implement a fully automatic system that allows you to quickly update software.
  
  
• Build your entire infrastructure using tools like Terraform, not through the cloud management console. Strive to implement the infrastructure as code approach. This will allow you, if necessary, to recreate everything with just one keystroke. Avoid manually creating cloud resources. Audit your configuration.
  
  
• Use centralized logging tools for all services. The logging system should be built so that you never need to connect to the system via SSH just to view or download the logs.
  
  
• Do not connect to services via SSH, with the exception of isolated cases of their diagnosis. Regular use of SSH usually means that your important tasks are not automated.
  
  
• Do not keep port 22 always open in any AWS service group. If you absolutely need SSH access, use only public key authentication, not logins and passwords.
  
  
• Prefer immutable hosts , rather than the long-lived servers that you patch and upgrade. Here is useful material on this topic.
  
  
• Use an intrusion detection system to minimize the damage from targeted cyber attacks.
  

Infrastructure operation

• Disable unused services and servers. The most secure server is the one from which the power cord was pulled out.
  

System testing

• Audit architecture and system implementation.
  
  
• Test your system for penetration - hack yourself. However, it is useful to involve outside experts in such tests.
  

Training

• Train staff (especially beginners) by talking about cyber risks and the methods of social engineering used to hack systems.
  

Contingency plan

• Create a threat model that describes what you defend against. It should list, with prioritization, possible threats and participants in the attacks.
  
  
• Prepare a clear contingency plan. One day you will need it.
  

Summary

The checklist in this article is not intended to be exhaustive. The thing is that each web project is unique and only its creators know exactly what threatens it, and how to deal with these threats. However, various projects have many common features. Therefore, we believe that everyone will be able to adjust the list presented here to their project.

What you read is based on more than fourteen years of experience as the author of the material in the development of secure web applications. This experience was not easy for him, and we are confident that his findings will make life easier for those who are concerned about the security of their web solutions.
Dear readers! What would you add to this list?