Reviewed August 31, 2026
Security
Client proposals contain pricing, scope and commercial terms, so it is fair to ask what protects them. Everything on this page was checked against the running code or a live response header before it was published. Where a claim could not be verified it is not here \u2014 and the second half of the page says plainly what we do not claim.
What is enforced
HTTPS on every request
Every request is served over HTTPS. Responses carry an HTTP Strict Transport Security header with a two-year max-age, which instructs browsers to refuse a plain-HTTP connection to this domain even if one is typed or linked. The content security policy also setsupgrade-insecure-requests, so a subresource requested over HTTP is upgraded rather than loaded insecurely.
Data at rest is encrypted by the hosting providers
The application database and uploaded files are hosted on Supabase; the application itself runs on Vercel. Both encrypt stored data at rest as a platform guarantee. We attribute this rather than claim it as our own control, because we do not operate a storage layer of our own \u2014 the encryption is the provider\u2019s, not something we implement, and we will not present it as ours.
Access rules enforced inside the database, not only in code
Row-level security is enabled on the tables that hold customer data, with explicit policies describing which rows a given signed-in user may read or write. The practical consequence is that a query which somehow bypassed an application-level check would still return nothing: the database itself refuses rows that do not belong to the caller\u2019s account or organisation. Authorisation does not depend on every code path remembering to ask.
Roles are checked on the server
Workspaces have owner, admin and member roles. Actions that read or change shared data resolve the caller\u2019s role on the server before touching anything \u2014 editing projects, managing shared templates, inviting and removing members, changing organisation settings. The interface hides what you cannot do, but hiding it is not the control; the server-side check is.
Client-facing proposal links are revocable, expirable and frozen
A shared proposal link does not render your live project. It serves a snapshot of the document and its branding captured at the moment you shared it, stored with a SHA-256 hash of that snapshot. Three consequences are worth knowing: editing the project afterwards does not silently change what an already-sent link shows; revoking a link stops it resolving immediately; and a link given an expiry date stops resolving once that date passes. Revocation and expiry are re-evaluated on every request rather than cached.
Rate limiting on public and AI endpoints
The public tool endpoints and the AI generation endpoints are rate limited using a sliding-window limiter backed by Upstash Redis. Requests over the limit receive a429response with aRetry-Afterheader. AI generation is additionally capped per account over rolling 24-hour and one-hour windows; the current allowances are published as usage limits on the pricing page rather than kept quiet as a security measure.
Browser hardening headers on every response
Every response ships a content security policy together with standard hardening headers: MIME-type sniffing disabled, framing denied outright, a strict-origin-when-cross-origin referrer policy, and camera, microphone and geolocation switched off through Permissions-Policy. We describe the policy as present rather than strict, because it currently permits inline and evaluated scripts \u2014 which a genuinely strict policy would not \u2014 and tightening it is outstanding work rather than a finished claim.
Card details never reach us
Byteflare AI does not collect, transmit or store card numbers. Payment is handled by Paddle, which acts as merchant of record, and card entry happens entirely inside Paddle\u2019s hosted checkout on their own domain. There is no card input field anywhere in our codebase, so there is no path by which card data could reach our servers or our logs.
What we do not claim
Security pages usually omit this section, which is exactly why it is worth reading.
- We hold no SOC 2 report, no ISO 27001 certificate and no third-party penetration test report. If any of those is a procurement requirement for you, say so in your first email rather than assuming — the honest answer today is that they do not exist.
- We publish no uptime figure and run no status page. We would rather omit a number than publish one we do not measure properly.
- We offer no data residency options. The stack runs in the United States — database, hosting and AI inference alike — as set out in the privacy policy.
- We run no paid bug bounty. Reports are still welcome and still answered.
Reporting a problem
Email support@byteflare.app with enough detail to reproduce the issue. If it involves personal data, use privacy@byteflare.app. Our commitment to notify affected customers of a personal data breach within 72 hours of becoming aware of it is a policy commitment rather than a technical control, so it lives in section 14 of the privacy policy, which this page complements rather than replaces.
For who is behind the product and how it is built, see about.