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 is subject to third-party penetration testing, covering the web application surface and the API. The date and scope of the most recent engagement are stated in the report, which is available to customers under a non-disclosure agreement on request through your account contact. See Vulnerability management for details.