Skip to main content

Application Security

This page describes how the Breeze application defends against common web-application threats.

Input sanitization​

User-supplied content that may be rendered as HTML — for example, credential template descriptions and rich-text fields — is sanitized through allowlist-based parsers:

  • HTML in templates is processed against a strict allowlist of permitted tags and attributes; anything outside the allowlist is stripped.
  • Markdown content is parsed and re-serialized against a conservative tag allowlist (headings, paragraphs, lists, code, tables, links) before being rendered in the browser.

This prevents stored cross-site scripting (XSS) attacks against tenant administrators viewing user-supplied content.

Injection protection​

  • NoSQL injection — All database access goes through a typed schema/validation layer. Query parameters are bound; there is no raw query construction from untrusted input.
  • SQL injection (AMR integrations) — Customer-managed Access Management Router integrations use parameterized SQL; see the AMR connectivity documentation for details.
  • Command and template injection — User input is never interpolated into shell commands or template strings on the server.

Rate limiting​

Rate limiting is applied per-endpoint in production, backed by a shared cache so limits apply across all instances of the backend. Authentication endpoints (/api/login, /api/activate, /oauth/token) and the GraphQL API each have dedicated per-source quotas, enforced regardless of authentication state. Suspicious user-agent and header patterns trigger additional throttling. Specific thresholds are available under NDA on request through your account contact.

Secrets management​

Operational secrets — including the JWT signing key, the field-level encryption key, the database connection string, and API credentials for sub-processors — are:

  • Never committed to source control. The repositories are protected by standard source-control controls; no secret material is checked in.
  • Injected at deploy time into the Azure App Service environment, sourced from a managed secret store.
  • Rotatable. The field-level encryption scheme supports key versioning, allowing the data-at-rest encryption key to be rotated without downtime.

GraphQL hardening​

  • Schema introspection is disabled in production deployments. The GraphQL schema is not retrievable via introspection queries from the public API.
  • The GraphQL endpoint is rate-limited as described above.
  • Every mutation flows through the centralized authorization guard; resolvers cannot bypass authentication or tenant-scoping.

Frontend defenses​

  • Markdown content rendered in the browser is sanitized against a strict allowlist before being inserted into the DOM.
  • The frontend stores no long-lived secrets. It does not hold database, blob-storage, or sub-processor credentials — those live only on the backend.

Software supply chain​

  • The frontend and backend are both type-checked on every pull request as part of the CI/CD pipeline.
  • Dependencies are pinned to exact versions, ensuring deterministic and reproducible builds.
  • Production deploys go through CI/CD; manual ad-hoc deployment is not part of the standard release flow.

Penetration testing​

The Breeze platform undergoes periodic third-party penetration testing. Most recent engagements focused on the authenticated web application surface and the API. Reports are made available to customers under a non-disclosure agreement on request through your account contact. See Vulnerability management for details.