Security

Most vendor security pages list certificates. Ours starts with architecture, because the strongest control is the one you can verify yourself in thirty seconds.

Last updated: July 2026

The short version: Sqwig runs entirely in your users' browsers. There is no Sqwig server in the data path — no user text, no telemetry, no license pings — so there is no Sqwig service to breach. The security surface that remains is the HTML the editor emits, and we test that adversarially. Found something? security@sqwig.com.

The architecture is the control

The Sqwig component is client-only: static files served from your origin, executing on the end user's device. It operates no servers, holds no user data, and makes zero network calls of its own — spellcheck runs against a dictionary downloaded with the component, and license keys are Ed25519-signed tokens verified offline, in code. You can confirm all of this in your browser's network tab, on this very site: the hero editor on the homepage is the shipped component.

That removes whole vulnerability classes by construction: no credentials or sessions for Sqwig to mishandle, no Sqwig-side database to inject into or exfiltrate, no server-side request forgery, no third-party data path to your users' words. What remains is a deliberately narrow surface:

The full security model — including the trust boundary your application owns (parameterized queries, server-side re-sanitization, CSP) — is documented for your engineers in the developer docs.

How we test it

Client-side filtering should never be anyone's only security boundary — including ours, which is why the docs tell your team to re-sanitize server-side. But we hold our boundary to an adversarial bar:

Reporting a vulnerability

Email security@sqwig.com with the package version and a minimal proof of concept. We acknowledge within 3 business days, assess confirmed issues within 14 days, and follow coordinated disclosure — up to 90 days from report to publication so a fix ships first, with credit to the reporter unless you prefer otherwise. Good-faith research within this policy will never be met with legal action. A SECURITY.md with the same policy ships inside every npm package.

For procurement: SOC 2, DPAs, and why the answer is different here

Security questionnaires assume a cloud service holding customer data. Sqwig isn't one, so two standard asks have non-standard — and stronger — answers:

"Send us your SOC 2."

A SOC 2 report audits a service organization's controls over the customer data it processes. Sqwig processes none: the component never transmits user content, and we operate no service in the data path. There is no processing environment to audit — the absence of the report reflects the absence of the risk, which is the outcome the questionnaire is probing for. (Editors that do carry SOC 2 carry it because their collaboration, conversion, and AI features send your users' text to their cloud.)

"Send us your DPA."

A Data Processing Agreement governs personal data processed on your behalf. Sqwig processes no personal data on your behalf, so there is nothing for a DPA to govern. Hand your procurement team this attestation:

Learn Wise Solutions LLC (d/b/a Sqwig) does not process personal data on behalf of its customers. The Sqwig component executes entirely within the end user's browser; no user content, telemetry, or license-verification traffic is transmitted to Sqwig or to any subprocessor, and Sqwig operates no infrastructure in the customer's data path. A Data Processing Agreement is accordingly inapplicable to the component. The only personal data Sqwig holds is the customer's own account and billing contact information, which Sqwig holds as an independent controller as described in its Privacy Policy.

Questions a questionnaire didn't anticipate? hello@sqwig.com — we answer these happily, in writing.