Security Policy

This document describes the security measures that are actually in place. Where something is not in place, it says so. Following ordinary information-security practice, it does not give specific detection thresholds, administrative paths, or configuration detail that could be used to attack the system.

1. Transport

Configuration at startup refuses to run in production if the application address is not HTTPS.

2. Passwords

There is no legacy hash format and no fallback path anywhere in the system — every password is scrypt.

There is no two-factor authentication for customers yet. That is a conscious decision at this stage and is recorded as work that should be done. Two-factor currently applies to operators only.

3. API keys

What this means for you: if you lose a key, TexAPI cannot send it back to you — only revoke it and issue a new one. If TexAPI’s database were read without authorisation, your keys could not be reconstructed from it.

Two limitations that have to be disclosed:

• Every key looks the same. The prefix shown in the interface is a fixed string for all keys, and TexAPI does not store the last four characters. Consequently: if you find a key leaked in a log or a commit, you have no way to identify which of your keys it is, and have to revoke on a guess. This is a real shortcoming and is being addressed.
• An API key is also accepted as a URL query parameter, for compatibility with some clients. URLs are written to the logs of every proxy and CDN along the way. Recommendation: always use the Authorization header.

4. TexAPI’s own and its suppliers’ secrets

Your API key is never forwarded to the infrastructure supplier. An authentication-header block list guarantees that; TexAPI uses its own key when calling the infrastructure.

One limitation to record: the key used to encrypt the secrets above is derived with a single simple hash and has no key version — meaning there is currently no path to rotate the encryption key. Recorded as work that should be done.

5. Sessions

The last two rows mean this: a token stolen on day one still works on day 30 unless you revoke it yourself. Which is why Settings → Security is a real tool, and worth using when something looks wrong.

6. Internal access control

The operator console is a separate application on its own domain, with its own cookie, an 8-hour session, and no search-engine indexing.

Role-based permissions, 6 roles and 50 distinct permissions. How it is enforced: the permission is the first mandatory argument of every administrative route, so a route that forgets to check one cannot be written. Every data-changing action goes through one single point, where an action does not compile unless it declares its permission, its audit action and its subject type.

Roles are designed on least privilege: the technical role has no financial permission at all; the finance role has no infrastructure permission and cannot read supplier secrets; the marketing role cannot see customers’ personal data; the support role can suspend and revoke but cannot issue refunds.

A role is looked up from the database on every request rather than baked into the session, so revoking a permission takes effect on the very next click — and the session of someone whose permissions were revoked is destroyed.

Money operations have two further barriers: a per-role amount ceiling, and a mandatory written reason on 13 kinds of sensitive permission. Two-factor authentication is mandatory for money operations above a threshold — an operator who has not enabled it is refused outright — but it is not yet mandatory for every operator, and is currently opt-in. There is no IP allow-list on the operator console.

7. Audit log

Every data-changing action by an operator is recorded, in the same database transaction as the change itself. Consequently: there cannot be a recorded change with no trail, nor a trail for a change that was rolled back. Failed actions and actions refused for lack of permission are recorded too.

What each entry holds: who did it, the action, the subject, the reason, the IP address, the browser information, a snapshot of the state before and after, a correlation id, and the outcome.

Append-only, and the database enforces this rather than a convention: a mechanism at the database layer blocks every update and delete on the log table — correcting a wrong entry has to be done by writing a compensating one. The actor’s email is stored denormalised deliberately, so that an operator whose account is deleted cannot delete their own history with it.

An honest limit: this blocks ordinary and accidental modification. It does not stop somebody with full database privileges.

8. Masking personal data in the operator console

Masking is done at the service layer, not the interface layer — meaning masked data is not present in the response at all, rather than merely hidden when displayed.

Unmasking requires a distinct permission that only 4 of the 6 roles hold.

Four identified masking gaps, being addressed — disclosed because half-masking is worse than none, since it creates a false sense of safety: the audit-log read surface returns unmasked state snapshots; the console overview embeds the most recent log entries without checking the personal-data read permission; display names are not masked anywhere; and the moderation excerpt is also written to the operational alerting surface, where there is no masking layer at all.

9. Rate limiting and abuse prevention

There are rate limits on: sign-in (by IP and by email), signup, forgotten password, password change, resending a verification email, the device-connection flow, redeeming a coupon, submitting a support ticket, every administrative route, and on API traffic itself.

The counters live in a shared cache with atomic operations. When the cache is unavailable, the system falls back to in-process counters rather than stopping enforcement — degrading to local, not opening the gate.

The per-plan numbers are in the API Terms. Abuse-detection thresholds are not published. Content moderation runs entirely in-process and does not send your content anywhere for analysis.

Two gaps, recorded honestly: there is no IP blocking, no blocklist and no country-level restriction — no table, no code and no configuration for any of it. And the route that consumes a password-reset token has no rate limit; the token is 256 bits so guessing is not a practical risk, but it is an ungated door.

10. Database and infrastructure security

The three backup rows are a serious shortcoming and TexAPI is not hiding them. What that means for you: keep your own copy of anything important — do not treat TexAPI as the only place holding something you cannot afford to lose.

11. Incident response

TexAPI commits to not concealing an incident that affects you, including where the cause was TexAPI’s own negligence.

12. Reporting a vulnerability

TexAPI welcomes vulnerability reports and will not take legal action against a researcher who follows the principles below.

Send to: support@texapi.dev with a subject beginning [SECURITY].

TexAPI’s commitments: acknowledge receipt within 3 working days; give an initial assessment within 10 working days; tell you when it is fixed; and credit you publicly if you would like that.

Permitted: testing against your own account; reading your own data; reporting logic flaws, authorisation flaws, authentication flaws and billing flaws.

Not permitted: accessing anyone else’s data — if you access it accidentally, stop at once, report it, and do not keep it; denial-of-service or load testing; automated testing that affects the service; social engineering aimed at TexAPI staff; physical testing; or disclosing a vulnerability before TexAPI has fixed it or before 90 days have passed.

TexAPI currently has no monetary bounty programme.

13. Your obligations

Security is shared. TexAPI cannot protect you from the following:

• Treat an API key like a password. Not in public source code, not in a screenshot, not sent over an unencrypted chat.
• Use a separate key per environment and per machine, so that you can revoke part rather than everything.
• Set a monthly spend cap on each key. This is the most effective damage limitation you can put in place yourself.
• Verify your email and keep your mailbox secure — it is the password-reset path.
• Review your sessions and your connected machines periodically; revoke anything you do not recognise.
• Report immediately if you suspect a key is exposed.

14. What TexAPI commits to doing next

This list is public because publishing a gap with a deadline is more trustworthy than staying silent about it.

Progress is reflected in this document as items are completed.