DEV Community

Hudson Tavares
Hudson Tavares

Posted on

Do not delegate the security to your code if you have don't have to

In modern web-based development, we moved from an era of custom hosting approaches based on physical servers to a services-based system, where cloud-based technologies host the different composing pieces of our software and manage the communication between them.

The own hosting definitions also became code in this new era, making technologies like Terraform, Pulumi, and CDK very popular (31.5k, 11.6k, and 8.5k Github stars, respectively) due to their deployment and orchestration capabilities.

As we deploy our code to the inherently secure cloud environments of Amazon, Google, Oracle, and others, we're prone to embrace the misleading assumption that these cloud providers will handle the main security points. At the same time, we remain responsible just for the code programming details.

This shallow thinking often leads to too permissive applications, which can cause issues like data loss or unintended access to other's data because of the underuse of the permissions systems provided on the own environment where they run. These security definitions outside the application code make them easier to test and more complicated to break by the code changes required over the software lifecycle.

The main points to turn these definitions into software development practices are:

  • It requires good team-level knowledge about the security options offered by the selected cloud provider. For instance, Amazon has Cognito as its user identity service and IAM for identity and access management.
  • The developers need a clear understanding of the boundaries of authentication and authorization and how they impact access to resources. Complex systems like SaaS applications may become more secure if they can segment the data they handle in different places per tenant instead of single storage relying on system rules. The access to the own data containers becomes tied to the user's related authorization before activating any code-level permission.
  • Ensure that automation can reliably evaluate these permissions as part of the continuous integration process, ensuring that the permissions granting and denial are in line with the expected behavior as the codebase evolves.

Top comments (0)