Application Security Architecture using Nest.js

Introduction to Application Security and Architecture using Nest.js, Node.js , TypeOrm, Swagger(OpenAPI), Docker, Kubernetes/mini-kube.

Application Security Architecture

One of the most prevalent cyberspace attack surfaces in any organization is its web applications. This fact stems from how easy it is to interact and poke around with Internet-facing web applications. In addition to malicious human actors, scanners and bots are used to detect vulnerabilities in APIs and Web Applications. There is an incremental growth in the scale of the attack surface that an attacker can exploit, every day cyber threats are emerging and the real battle is mitigating them before an adversary capitalize on them. It’s also worth to note

(See log4j-log4shell and more common exploits that sweep the cyberspace)

It’s important to note that most of the security problems comes from faulty architecture and design patterns in the code.

Applications develop and change every day, be it externally or internally. The internal improvement consists of changes introduced during the Development Life Cycle of an application, such as adding API routes, changing cloud configurations, introducing new code, etc... External changes may include changes of dependencies, vendors, external api, and much more.

Security issues of an application emerge from action or inaction of internal and external changes. Attack surface changes daily and the application security engineer's job is to Detect, Mitigate and Monitor those threats.

Shift left - the idea that tells us to integrate security much earlier in the development life cycle. It is exponentially cheaper for an organization to integrate secure design in the architecture of our software early on. Consider the increasing cost of data breaches, which could potentially result in losing business, exposure to lawsuits, additional IT costs, higher emergency mitigation costs, Incident response expenses. Now compare it to the fractional cost of developing a secure application in the first place. And although developing applications is costly, adding security after the fact is detrimental to the security of any size organization.

Employing a Secure Software developer lifecycle, aim to minimalize the attack surface and the related costs of a data breach.

SSDLC mostly consists of the following practices in the software development stages:

• Design - Security requirements, Secure Coding standards, Threat Modeling, Security Architecture

• Development - Secure Coding Standards, Secure Design Patterns and Frameworks, Secure Coding Practices

• Testing - Secure Code Review, Vulnerability Assessment

• Deployment - Secure requirements

• Maintenance - Security Patch Updates

A big aspect of our secure architecture that would help us scale better, integrate security by design, and push our code continuously, is using containers. Using a container reduces the surface of our microservice to API endpoints, allowing us to test our environment for bugs and security issues, as well as limit interaction to other parts of our architecture such as the DB, we can deploy our micro-service using code, and test this code. Using a container orchestration service such as Kubernetes, mini-kube. Would help us scale, deploy CDNs and adhere to best practices that are battle-tested for this specific usage. Using containers helps us to monitor the environment for dependency issues and better control the code that runs. At a later maturity level of an application, using Containers help us govern our IaC(Infrastructure as code) policies, and tighten security. All the while allowing our developers to build, test, and push as easy as can be.

Our shopping list for a secure web application for the enterprise-level need to include:

• Modern extensible IDE - To help us develop faster and securely using security tools.

• Version control - To track code changes, deploy versions, and fix issues.

• Containers - To encapsulate our product and help with end-to-end testing

• Framework/languages - We need a framework that would play well with our growth philosophy, give us battery included architecture that is easy to secure, maintain, and develop in teams. Bonus points if it has a great community and can be extended with 3rd party modules to help ship faster.

• CI/CD - Deployment pipeline that tests for known security issues, mis-configurations, hardcoded secrets, known vulnerabilities.

• Monitoring - testing, vulnerability assessment, logging

So we are focusing our stack of choice on the fundamental security requirements that would allow our developers to code securely, let’s dive deeper into the meat of the stack and justify our technology choices with our proposed security and development principles.

JavaScript is the de facto language of the internet, one-up it with TypeScript for static typing, classes, and interfaces, to help with debugging (why not sprinkle a bit of OOP). Node.js is a front runner in the full-stack eco-system it plays well with agile and scrum methodologies to deliver fast and scalable results and could also be secure. The crown jewel, in my opinion, is its npm/yarn package managers which allow a lot of integration with the pre-baked codebase.