TeXTypeSign inSecurity
Last reviewed September 27, 2026
TeXType takes security seriously. Below is a description of how TeXType takes best efforts to protect your work as of the date above. It is not a certification or guarantee; our responsibilities are the ones described in the Terms of Service.
In short
- Sign-in via Google (OAuth 2.0 and OpenID Connect), GitHub (OAuth 2.0 with PKCE, no access kept afterwards) or Microsoft (OpenID Connect with PKCE; a work or school address is accepted only when Microsoft confirms the organisation owns it). Sessions end after 12 hours unused and 7 days at most. Sign-out from every device at once from the account page.
- Traffic goes through Cloudflare, which filters attacks and rate-limits sign-in. Connections are HTTPS only, with HSTS and TLS 1.3 for current browsers. Cloudflare connects to our server over TLS too, and the server accepts connections only from Cloudflare, which must present its client certificate (mutual TLS).
- Documents are compiled in an isolated sandbox with no network access.
- Project saves are version-controlled with git, with no setup required.
- Pro users can sync projects to GitHub or GitLab, and can configure an external push to remote on save.
- Automatic nightly backups, both on AWS and Backblaze.
Who else handles data
- Cloudflare: the network edge (DNS, TLS, attack filtering)
- Amazon Web Services: the server and its snapshots
- Backblaze: off-site backups
- Google: sign-in
- Microsoft: sign-in
- Stripe: payments
- Resend: account emails
- Sentry: error reports
- GitHub: sign-in, and our code (not your documents)
The privacy notice says what each one receives.
Reporting a problem
If you find a security problem, please email [email protected] rather than posting it publicly, with what you found and how to reproduce it. We will work in a timely fashion to ensure the problem is resolved, and keep you updated on our progress.
We will not pursue legal action against good-faith research that follows the rules listed below:
- test only against your own account and projects;
- do not access, change or keep anyone else's data;
- do not degrade the service: no denial of service, spam or high-volume automated scanning;
- give us 90 days to fix any problems before disclosure.
Social engineering, physical attacks, the services listed above, and scanner output without demonstrated impact are out of scope for good-faith research described above. We do not run a paid bug bounty yet; however, we will credit you here for any findings, and provide your account a free year of Pro. The same policy is at /.well-known/security.txt.
If something goes wrong
We maintain a written plan of action in the case of a security incident, and will inform you of what happened and what you can do within 72 hours of incident confirmation.
Checklist
The list below represents an informal internal security assessment, grouped by the core six functions of the NIST Cybersecurity Framework 2.0. Items that are marked in place below are valid as of the release date marked at the top of this document.
29 in place0 in progress0 planned
Govern
- In placeSecurity policy (this document) is reviewed quarterly
Identify
- In placeExternal services are identified (see above)
- In placeAn externally stored private register of operator accounts, recovery methods, multi-factor status and recovery codes
- In placeA written threat model and data classification
- In placeRuntime dependencies are validated for known vulnerabilities prior to releases
Protect
- In placeOAuth only login
- In placeBounded sessions that can be ended on demandSessions lapse after 12 hours unused and 7 days at most, and can be ended on every device at once.
- In placeMulti-factor sign-in on every operator account
- In placeAdministrative access to the server is closed to the internet
- In placeEnd to end encryptionTLS from the browser to Cloudflare and from Cloudflare to the server, with HSTS.
- In placeAccess tokens for syncing to GitHub or GitLab are stored encrypted
- In placeNightly snapshots of the whole server on AWSSeven days of automatic snapshots.
- In placeNightly backups off AWSEvery project, its history and the database, to Backblaze. 14 nightly and 6 monthly copies are kept.
- In placeOff-AWS backups cannot be deleted or altered for 14 days
- In placeOff-AWS backups are encrypted with a key the storage provider does not have
- In placeDocuments are compiled in an isolated sandboxNo network access, a read-only system, no special privileges and a restricted shell escape.
- In placeUploaded files cannot run in your browserFiles are served as downloads under a sandboxing content policy.
- In placeOperating system security updates applied automatically
- In placeAttacks are filtered at the network edgeCloudflare absorbs denial-of-service traffic and rate-limits sign-in before it reaches the server.
- In placeThe server only accepts traffic from CloudflareA firewall admits only Cloudflare's addresses, and each connection must present Cloudflare's client certificate.
- In placeLimits on CPU-intensive user actions
Detect
- In placeErrors and failures are monitoredServer and browser errors are reported, with alerts for low disk, stale backups, failed saves and compiles that cannot run.
- In placeRequest logs and administrative actions are copied off the server hourlyEach administrative action is recorded with who made it and when. These backups cannot be altered and are kept for 30 days.
- In placeAlerts for unusual accessServer logins and suspicious activity are reported off the server in real time.
- In placeThe server is checked hourly for changes inconsistent with externally-validatable releases
Respond
- In placeWe maintain an incident response plan
- In placeA way to report a vulnerabilitySee "Reporting a problem" above.
Recover
- In placeAny component of the system, from single files to the entire infrastructure, is restorable from the backup structure outlined in this document
- In placeFull restores from backups tested quarterlyLast passed 28 September 2026.