Security

Last updated: April 23, 2026

Security is a continuous commitment at EasySchema. This page describes our security practices and how to report vulnerabilities responsibly.

Infrastructure

• Encryption in transit — all traffic uses TLS 1.2 or higher. HSTS is enabled on our production domains.
• Encryption at rest — data stored in our primary database is encrypted at rest.
• Network isolation — internal services are not exposed to the public internet. Our proxy explicitly blocks requests to private IP ranges, loopback addresses, and cloud metadata endpoints (SSRF protection).
• Hardened infrastructure — operating systems, runtime, and dependencies are kept up to date with security patches.

Application Security

• Authentication — Tringify proves your identity using Authorization Code with PKCE and a signed identity token. EasySchema then creates a local session whose random token is stored only as a SHA-256 hash.
• Account security — passwords, multi-factor authentication, passkeys, and account recovery are managed by your Tringify account rather than duplicated inside EasySchema.
• Role-based access control — workspace permissions are enforced at every endpoint with a strict allow-list model.
• Rate limiting — Tringify protects identity operations, while EasySchema separately rate-limits the sensitive account and session operations it owns.
• Input validation — all user input is validated and bounded. Maximum request body sizes are enforced.
• Secure defaults — cookies are HttpOnly, Secure, and SameSite=Lax. CORS is allowlisted.

Data Handling

• Retention — webhook payloads and audit logs follow plan-specific retention windows.
• Data deletion — accounts scheduled for deletion are fully removed after the grace period. Workspace and request data is deleted with the owning account.
• Audit logging — sensitive actions are logged with user, workspace, IP, timestamp, and action details. Logs are available to workspace owners.
• Backups — databases are backed up regularly. Backups are encrypted and access-controlled.

Development Practices

• Code review for all production changes
• Dependency monitoring for known vulnerabilities
• Periodic internal security reviews
• Least-privilege principles for staff access to production systems

Responsible Disclosure

We appreciate security researchers who help us keep EasySchema safe. If you discover a vulnerability:

1. Email security@easyschema.xyz with details of the issue.
2. Give us reasonable time to investigate and remediate before public disclosure (we aim for initial response within 3 business days and remediation timelines depending on severity).
3. Do not access, modify, or delete data that isn't yours.
4. Do not perform tests that could degrade service availability for other users.
5. Do not use social engineering, physical attacks, or third-party services.

We commit to:

• Responding to your report promptly
• Keeping you informed of our progress
• Not pursuing legal action against researchers who act in good faith and follow this policy
• Publicly crediting you (with your permission) once the issue is resolved

Scope

In-scope targets:

• easyschema.xyz and all subdomains
• api.easyschema.xyz
• app.easyschema.xyz
• docs.easyschema.xyz

Out of scope:

• Customer-operated doc sites on custom domains (unless directly exploitable against our platform)
• Third-party services we use (Tringify Billing, SSO — report those to the respective vendor)
• Social engineering and physical attacks
• Issues requiring compromised or rooted user devices
• Missing best-practice headers with no demonstrable impact
• Self-XSS or attacks that require the victim to perform unusual actions

Sub-processors

See our Data Processing Agreement for a current list of sub-processors handling your data.

Contact

Security issues: security@easyschema.xyz
Privacy inquiries: privacy@easyschema.xyz