application_security/architecture

265 notes in this subject, read out of this brain and free to use. This is page 3 of 5.

Network-level DoS defense: host static resources on different domain

Host static resources (images, JavaScript) on a different domain from the main application to reduce the number of HTTP requests to the web application and improve resilience against network-level DoS attacks.

ISP-level DoS remediations: filter invalid sender addresses

Filter invalid sender addresses using edge routers in accordance with RFC 2267 to filter out IP-spoofing attacks designed to bypass block lists.

ISP-level DoS remediations: evaluate ISP DDoS capabilities

Check ISP services in advance regarding DDoS support, including: support for multiple internet access points, sufficient bandwidth (xx-xxx Gbit/s), and special hardware for traffic analysis and defense at application level.

Commercial cloud filter services for large-scale DoS attacks

Consider using commercial filter services to resist larger DoS attacks up to 500 Gbit/s. These services support different mechanics to filter malicious or non-compliant traffic. Be aware that many providers route traffic through USA/UK, which may create data protection and privacy compliance concerns.

CIA triad availability component in DoS context

Availability is a basic part of the CIA triad (Confidentiality, Integrity, Availability). A successful DoS attack hinders availability of instances or objects and can render the entire system inaccessible.

Immutable infrastructure principle for IaC

Immutable infrastructure means building infrastructure components to exact specifications with no deviations or changes. If changes are required, a whole new set of infrastructure must be provisioned based on updated requirements, and the old infrastructure is decommissioned.

IDE plugins for IaC security scanning

IDE plugins help detect potential security risks early in the development cycle. Named tools include TFLint, Checkov, Docker Linter, docker-vulnerability-extension, Security Scan, and Contrast Security for security assessment of Infrastructure as Code.

Static analysis tools for IaC

Static analysis tools that analyze code in isolation to identify risks, misconfigurations, and compliance faults in Infrastructure as Code include kubescan, Snyk, and Coverity.

Open source dependency analysis tools for IaC

Tools for analyzing open source dependencies such as OS packages and libraries to identify potential risks in Infrastructure as Code include BlackDuck, Snyk, and WhiteSource Bolt for GitHub.

Container image scanning tools

Container image scanning tools that analyze contents and build processes to detect security issues and vulnerabilities include Dagda, Clair, Trivy, and Anchore.

CI/CD pipeline and consolidated reporting tools

Jenkins can be leveraged to build CI/CD pipelines with security checks integrated for each code change. DefectDojo and OWASP Glue help consolidate check results and visualize them in a single dashboard.

Artifact signing for Infrastructure as Code integrity

Digital signing of artifacts at build time and validation of signed data before use protects artifacts from tampering. TUF is an open-source tool that helps with digital signing of artifacts to ensure integrity and provenance.

Dynamic analysis tools for IaC

Dynamic analysis tools evaluate existing environments and services for potential interoperability risks. Open-source tools for dynamic analysis include ZAP, Burp, and GVM.

Log analysis tools for infrastructure monitoring

Security logs and audit logs should be enabled during infrastructure provisioning. ELK is an open-source tool that can be leveraged for log analysis to assess security risks and analyze incident root causes.

Infrastructure monitoring tools

Continuous monitoring assists in detecting security and compliance violations and identifying attacks. Open-source tools for monitoring cloud infrastructure include Prometheus and Grafana.

Runtime threat detection tools

Runtime threat detection solutions recognize unexpected application behavior and alert on threats at runtime. Open-source tools include Falco. Contrast Community Edition can detect OWASP Top 10 attacks during runtime and help block them.

IaC inventory management for deployed resources

Commissioning requires labeling, tracking and logging resources as part of inventory management when deployed. Decommissioning requires erasing underlying configurations, securely deleting data, and completely removing resources from runtime and inventory.

Tagging cloud assets in IaC

Cloud assets must be properly tagged during Infrastructure as Code operations. Untagged assets result in ghost resources that make detection and observability difficult, affect security posture, increase billing costs, and complicate maintenance.

Principle of least privilege for IaC access

Define access management policies for IaC based on principle of least privilege: define who is authorized to create/update/run/delete scripts and inventory; limit authorized IaC user permissions to only what is necessary; ensure IaC scripts grant resource permissions limited to what is required for resource functionality.

Version control for Infrastructure as Code

Track and manage all changes to Infrastructure as Code with version control. Feature infrastructure requirements should be part of a feature branch or merge request, not checked in separately. Git is typically used as the source code version control system.

Threat modeling in IaC development cycle

Build threat modeling landscape early in the development cycle to provide visibility of high-risk, high-volume aspects of code and ensure flexibility to include security throughout to safely manage assets.

Android app integrity verification using Play Integrity API

Implement Google's Play Integrity API for device and app integrity checks. Obtain an integrity verdict from the device and validate it server-side, then take action if integrity checks fail. The SafetyNet Attestation API was fully turned down in January 2025; all developers must migrate to Play Integrity API.

Android code obfuscation tool

Use Android's ProGuard for code obfuscation to protect mobile application binaries.

iOS App Attest API for app integrity validation

Use Apple's App Attest API (iOS 14+) to validate app integrity. Generate attestation keys and assertions with `DCAppAttestService` and verify assertions server-side. Complement with Apple's DeviceCheck API for persistent device state tracking.

Mobile app permission principle of least privilege

Request only the permissions your app needs, including both device permissions granted by the user and permissions granted to the app by backend services. Avoid storing application files with overly permissive permissions. Applications should have the most secure settings by default.

Mobile app signing requirement

Ensure app signing as part of supply chain security controls.

Mobile third-party library security controls

Use only trusted and validated third-party libraries and components. Establish security controls for app updates, patches, and releases. Monitor and detect security incidents of used third-party products.

Mobile code tampering detection

Include client-side code to detect code or binary tampering in mobile applications.

Mobile UI sensitive information masking

Mask sensitive information on UI fields to prevent shoulder surfing in mobile applications.

Mobile security notification to users

Inform the user about security-related activities, such as logins from new devices, in mobile applications.

Mobile static analysis tools

Use static analysis tools to identify vulnerabilities in mobile applications.

Mobile security-focused code reviews

Make security a focal point during code reviews of mobile applications.

Mobile library update maintenance

Keep all libraries up to date in mobile applications to patch known vulnerabilities.

Mobile debugging disabling

Disable debugging in mobile applications.

Mobile application code integrity validation

Include code to validate integrity of application code in mobile applications.

Mobile app binary obfuscation

Obfuscate the app binary in mobile applications.

Mobile runtime anti-tampering controls

Implement runtime anti-tampering controls in mobile applications: check for signs of debugging, hooking, or code injection; detect if the app is running in an emulator or rooted/jailbroken device; verify app signatures at runtime; apply appropriate responses to detected tampering (e.g., limiting functionality).

Mobile penetration testing

Perform ethical hacking to identify vulnerabilities in mobile applications. Example tests include cryptographic vulnerability assessment and attempting to execute backend server functionality anonymously by removing any session tokens from POST/GET requests.

Mobile automated security testing

Leverage automated tests to ensure that security features are working as expected and that access controls are enforced in mobile applications.

Mobile security usability testing

Ensure that security features do not harm usability in mobile applications, which could cause users to bypass security features.

Mobile incident response planning

Have a clear incident response plan in place for mobile applications.

Mobile update and patch planning

Plan for regular updates and patches in mobile applications. Use a mechanism to force users to update their app version when necessary due to the delay between when a patch is released and when users actually receive the updated version.

Mobile monitoring and analytics for threat detection

Use real-time monitoring to detect and respond to threats in mobile applications.

Use explicit Node.js Docker base image with SHA256 digest

Always specify Node.js Docker base images with both the tag and the SHA256 digest to ensure deterministic builds. Example: FROM node:lts-alpine@sha256:b2da3316acdc2bec442190a1fe10dc094e7ba4121d029cb32075ff59bb27390a. This prevents inconsistent builds from pulling different versions of the same tag and reduces the image size and vulnerability surface. Use 'docker pull node:lts-alpine' to get the digest, or 'docker images --digests' to view it for a locally-pulled image.

Install only production dependencies in Docker image

Use 'RUN npm ci --omit=dev' to install only production dependencies in the Docker image. Do not use 'RUN npm ci' which installs all dependencies including devDependencies. This reduces security risk from development packages and reduces image size. The npm ci command enforces deterministic builds by halting if any deviations from the lockfile are made.

Set NODE_ENV to production in Docker image

Add 'ENV NODE_ENV production' to the Dockerfile to enable production-specific optimizations in frameworks and libraries. Many frameworks and libraries, such as Express, only activate optimized configuration for performance and security when NODE_ENV is set to production. This setting has significant performance impact beyond just dependency installation.

Run Docker containers as non-root user

Use the 'node' user provided by the official node Docker image instead of running as root. Apply 'COPY --chown=node:node' to ensure files are owned by the node user, then use 'USER node' before CMD. This follows the principle of least privilege and prevents attackers who compromise the application from gaining root-level access for command injection, directory traversal, container escape, or privilege escalation.

Use dumb-init to properly handle signals in Node.js containers

Install dumb-init with 'RUN apk add dumb-init' and invoke it in the CMD directive as 'CMD ["dumb-init", "node", "server.js"]' to act as an init process for PID 1. This ensures all signals like SIGTERM and SIGINT are properly proxied to the Node.js process. Do not use shell form CMD (CMD "npm" "start") which wraps the process in a shell that may not forward signals. Use exec form notation (JSON array) for CMD to directly spawn the process without shell wrapping. Node.js running as PID 1 does not respond to signals by default because the kernel treats PID 1 differently.

Implement graceful shutdown in Node.js applications

Set event handlers for SIGINT and SIGTERM signals to allow graceful shutdown. Example with Fastify: 'async function closeGracefully(signal) { console.log(`Received signal to terminate: ${signal}`); await fastify.close(); process.exit(); } process.on('SIGINT', closeGracefully); process.on('SIGTERM', closeGracefully)'. The handler should wait for cleanup operations like database connections and ongoing HTTP requests before terminating the process. Fastify.close() also responds to new connections with HTTP 503 status to signal unavailability.

Use multi-stage Docker builds for Node.js applications

Separate the build stage from the production stage using multi-stage builds. The build stage uses a larger image (e.g., node:latest) to install dependencies and compile native packages. The production stage uses a minimal image (e.g., node:lts-alpine) with only runtime artifacts copied from the build stage. Copy node_modules from build stage using 'COPY --chown=node:node --from=build /usr/src/app/node_modules /usr/src/app/node_modules'. This prevents sensitive information from appearing in the final image and reduces image size. Mark build stages with 'AS build' alias.

Create .dockerignore file to prevent unnecessary file copying

Create a .dockerignore file with glob patterns to prevent unnecessary files from being sent to the Docker daemon. Include: .dockerignore, node_modules, npm-debug.log, Dockerfile, .git, .gitignore, and .npmrc. This prevents leaking modified node_modules, secrets like .env or aws.json files, and avoids cache invalidation from unrelated file changes. This is especially important with multi-stage builds where 'COPY .' operations would otherwise copy sensitive local files into production images.

Complete Node.js Docker multi-stage Dockerfile example

FROM node:latest AS build WORKDIR /usr/src/app COPY package*.json /usr/src/app/ RUN --mount=type=secret,mode=0644,id=npmrc,target=/usr/src/app/.npmrc npm ci --omit=dev FROM node:lts-alpine@sha256:b2da3316acdc2bec442190a1fe10dc094e7ba4121d029cb32075ff59bb27390a RUN apk add dumb-init ENV NODE_ENV production USER node WORKDIR /usr/src/app COPY --chown=node:node --from=build /usr/src/app/node_modules /usr/src/app/node_modules COPY --chown=node:node . /usr/src/app CMD ["dumb-init", "node", "server.js"] Build with: docker build . -t nodejs-tutorial --secret id=npmrc,src=.npmrc

Alpine base image reduces vulnerability footprint

Use node:lts-alpine as the base image for production Node.js Docker images instead of the full node image. The full node image includes hundreds of unnecessary libraries and tools that increase download size and introduce security vulnerabilities. Alpine provides a minimal image that reduces the vulnerability surface and speeds up image build and deployment time.

npm ci command enforces deterministic builds

Use 'npm ci' (clean install) instead of 'npm install' in Docker images. The npm ci command reads from package-lock.json and halts if any deviations from the lockfile are detected, preventing surprises in continuous integration flows and ensuring reproducible builds across environments.

Secure Product Design methodology: two processes

Secure Product Design is achieved through two processes: Product Inception (when a product is conceived or re-invented) and Product Design (continuous, evolutionary, done in an agile way close to where code is written).

Secure Product Design core approach

The basic start for Secure Product Design is to establish secure defaults, minimize the attack surface area, and fail securely to well-defined and understood defaults.

Least Privilege principle definition

Least Privilege is a security principle that states users should only be given the minimum amount of access necessary to perform their job, with access limited to resources needed and no more. This reduces the risk of unauthorized access to sensitive data or systems.

Separation of Duties principle definition

Separation of Duties is a fundamental principle of internal control that ensures no single individual has control over all aspects of a transaction by assigning different tasks to different people. This helps reduce fraud risk, prevents errors, and ensures all tasks are completed in a timely manner.

Defense-in-Depth principle definition

Defense-in-Depth is a security strategy involving multiple layers of security controls to protect organizational assets. Layers can include physical security, network security, application security, and data security. If one layer fails, other layers still protect the asset, creating a resilient environment that can detect and respond to security incidents while minimizing successful attack damage.

Security-in-the-Open concept for open source development

Security-in-the-Open emphasizes the importance of security in open source software development, requiring developers to be aware of security implications of their code and take steps to ensure security. This includes using secure coding practices, testing for vulnerabilities, using secure development tools, and collaborating with security experts.

Give your agent this brain