Security

OWASP Top 10

The OWASP Top 10 is a widely recognized standard awareness document for web application security. It represents a broad consensus about the most critical security risks to web applications. At 21RISK we use the OWASP Top 10 as a guideline for building and maintaining a secure application.

This document describes each of the OWASP Top 10 - 2021 risks and how we address them at 21RISK.

A01:2021 - Broken Access Control

Broken access control occurs when users can act outside of their intended permissions. It is the most common and critical web application security risk.

Read more at OWASP

How we address this at 21RISK

  • Role-Based Access Control (RBAC): 21RISK implements a fine-grained permission system. A role can have one or more permissions, and customers can create custom roles tailored to their organization. Users can only perform actions allowed by their assigned role.
  • Principle of Least Privilege: Users are granted only the minimum access necessary to perform their duties. Access can be scoped to specific locations, boards, and areas, ensuring users only see and interact with resources relevant to them.
  • Server-side authorization: All mutations and queries are validated on the server to ensure the requesting user has the required permissions and resource access. We never rely solely on client-side checks.
  • Secure session management: Sessions are managed using secure, HttpOnly, SameSite cookies, scoped to the 21RISK domain. Every request is validated against the session store, allowing us to immediately invalidate compromised sessions.

A02:2021 - Cryptographic Failures

Cryptographic failures relate to weaknesses in encryption that can lead to exposure of sensitive data such as passwords, credit card numbers, or personal information.

Read more at OWASP

How we address this at 21RISK

  • Encryption in transit: All traffic is served over HTTPS with TLS, enforced by the Vercel platform. HTTP is automatically upgraded to HTTPS, and older insecure TLS versions are not supported.
  • Encryption at rest: Our database provider Planetscale automatically encrypts all stored data at the filesystem level, including backups.
  • Secrets management: All secrets are stored in Doppler (a secrets-as-a-service platform) and are never committed to source code or exposed in client-side bundles. Production secrets are embedded at build time via the Vercel CLI and are not synced directly to the Vercel dashboard.
  • Secure password handling: We delegate authentication to trusted identity providers via SSO (OAuth 2.0 with PKCE). API keys are stored as SHA-256 hashes; the raw key is only shown to the user once at creation time.

A03:2021 - Injection

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. This includes SQL injection, NoSQL injection, OS command injection, and Cross-Site Scripting (XSS).

Read more at OWASP

How we address this at 21RISK

  • Parameterized queries: We use Drizzle ORM for all database interactions, which uses parameterized queries by default, preventing SQL injection.
  • XSS prevention: SvelteKit escapes dynamic content in templates by default, preventing the execution of malicious scripts injected into data. We further enforce this with a Content Security Policy (CSP) header that restricts where resources can be loaded from.
  • Input validation: All user input is validated using Zod schemas on the server side before being processed. This ensures that only well-formed, expected data reaches our business logic and database layers.
  • HTTP security headers: We configure security headers including Content-Security-Policy and X-Content-Type-Options to provide defense-in-depth against injection attacks. Our headers can be inspected at securityheaders.com .

A04:2021 - Insecure Design

Insecure design refers to risks related to missing or inadequate security controls built into the application from the design phase. Even a perfect implementation cannot fix an insecure design.

Read more at OWASP

How we address this at 21RISK

  • Security-first development: Every pull request goes through a mandatory code review by at least one other developer. The review process has a strong focus on security, ensuring that new code not only works but is also secure.
  • Security principles: We follow a documented set of security principles - including hiding internal errors, preventing resource enumeration, and applying the Principle of Least Privilege - that guide design decisions from the start.
  • Automated testing: Our comprehensive test suite (unit tests, integration tests, end-to-end tests, and visual tests) helps ensure that security controls work as intended and are not inadvertently weakened during development.
  • Threat-aware architecture: 21RISK is designed as a Multi-Page Application (not a SPA), which allows us to store sensitive state in secure HttpOnly cookies rather than in client-side storage, protecting against a range of token-based attacks.

A05:2021 - Security Misconfiguration

Security misconfiguration is the most commonly seen issue and can happen at any level of an application stack, including default configurations, incomplete configurations, or verbose error messages.

Read more at OWASP

How we address this at 21RISK

  • Hidden internal errors: Only expected errors are shown to users. Unexpected errors display a generic error message with an error ID, while the full details are logged internally. This prevents attackers from gaining knowledge about our internals.
  • Secure HTTP headers: We configure strict security headers including Content-Security-Policy, Strict-Transport-Security (HSTS), X-Frame-Options, and X-Content-Type-Options. We do not expose server or technology details via headers like Server or X-Powered-By.
  • Platform-managed security: By running on Vercel, we benefit from secure defaults for TLS configuration, DDoS mitigation, and edge network security, reducing the surface area for misconfiguration.
  • Minimal feature exposure: We only enable the Vercel platform features we actively use (serverless functions), and disable or ignore unused features, reducing the attack surface.

A06:2021 - Vulnerable and Outdated Components

Using components with known vulnerabilities can undermine application defenses and enable various attacks. This includes libraries, frameworks, and other software modules.

Read more at OWASP

How we address this at 21RISK

  • Automated vulnerability scanning: We use Snyk and Dependabot to continuously monitor our dependencies for known vulnerabilities. When a vulnerable dependency is found, we are automatically notified in our communications channel.
  • Regular updates: Combined with a daily release cycle, we keep dependencies up to date and patch vulnerabilities quickly. We also use npm audit and npm outdated to proactively check for issues.
  • Dependency evaluation: Before integrating a new dependency, we critically evaluate whether it is truly needed. We minimize the number of third-party packages to reduce our attack surface.
  • Locked dependencies: In production we use npm ci to install from the lock file, ensuring that the exact versions committed to version control are deployed.

A07:2021 - Identification and Authentication Failures

Authentication failures allow attackers to compromise passwords, keys, or session tokens, or to exploit implementation flaws to assume other users' identities.

Read more at OWASP

How we address this at 21RISK

  • No password storage: 21RISK does not store any passwords. Users authenticate via email-based authentication or SSO, with credential management delegated to trusted identity providers (e.g., Azure AD) using the OAuth 2.0 Authorization Code Flow with PKCE.
  • Multi-Factor Authentication (MFA): We enforce two-factor authentication on all the services we use, adding an extra layer of protection against credential compromise.
  • Secure session management: Session IDs are cryptographically strong random values. Sessions are validated on every request, and cookies are configured with Secure, HttpOnly, and SameSite attributes.
  • Protection against common attacks: Our MPA architecture with server-managed sessions protects against CSRF, login mixup attacks, token substitution, and stolen token injection. PKCE prevents authorization code interception.

A08:2021 - Software and Data Integrity Failures

Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations, including insecure CI/CD pipelines and untrusted software updates.

Read more at OWASP

How we address this at 21RISK

  • Code review process: No code is merged into the main branch without review by at least one other developer. All changes are tracked in a single Git repository with complete commit history.
  • Locked dependency installation: We use npm ci in production builds, which installs dependencies strictly from the lock file, ensuring reproducible and tamper-resistant builds.
  • Automated CI/CD pipeline: Our CI pipeline runs automated tests (unit, integration, end-to-end, and visual) on every pull request. Code can only be merged if all tests pass.
  • Supply chain monitoring: Snyk and Dependabot continuously scan our dependency tree for compromised or vulnerable packages, alerting us to supply chain threats.

A09:2021 - Security Logging and Monitoring Failures

Without effective logging and monitoring, breaches cannot be detected in a timely manner, making it difficult to respond to incidents and perform forensic analysis.

Read more at OWASP

How we address this at 21RISK

  • Centralized error logging: All application errors are logged and reported to our centralized error logging system, with structured data that enables quick triage and investigation.
  • Session activity logging: We log all session activity and periodically inspect suspicious activity, helping us detect unauthorized access attempts.
  • Incident response plan: We maintain a documented incident response plan that defines how we detect, escalate, and respond to security incidents. This includes defined roles, communication protocols, and post-incident review processes.
  • Automated alerts: Vulnerability notifications from Snyk and Dependabot are automatically routed to our communications channel, ensuring the team is promptly informed of potential threats.

A10:2021 - Server-Side Request Forgery (SSRF)

SSRF flaws occur when a web application fetches a remote resource without validating the user-supplied URL. This can allow attackers to access internal services or scan internal networks.

Read more at OWASP

How we address this at 21RISK

  • Serverless architecture: 21RISK runs on Vercel's serverless platform, where functions are stateless and ephemeral. This architecture inherently limits the ability to access internal networks or persistent server-side resources.
  • Input validation: All user-supplied input, including URLs and external references, is validated using Zod schemas before being processed by the server.
  • Network isolation: By using managed services (Vercel for compute, Planetscale for database, Doppler for secrets), we minimize the internal network surface that could be targeted by SSRF attacks. There are no internal services exposed on a traditional network that an attacker could reach.
  • Edge network protection: Vercel's edge network provides additional layers of protection including DDoS mitigation, spoofing protection, and request filtering.
previous Incident response plan
next Acceptable Use Policy