Security
Security Plan
Last updated: October 2026. Version 1.4. Public document for customers and partner reviews (e.g. TikTok Shop Partner). Portuguese edition: /seguranca.
1. Purpose and scope
This Security Plan describes the technical and organisational measures applied by Syntra (Maranata Software) to protect account data, orders, financial data, marketplace and ERP integrations (including TikTok Shop, Mercado Livre, Shopee, SHEIN, Amazon, Bling, Tiny and Omie) and OAuth credentials. It covers the web application and APIs at getsyntra.com.br, the production infrastructure, webhooks and staff access to production. It complements the Privacy Policy at /privacidade.
2. Data classification
Public: marketing pages and public documents. Internal: aggregated operational metrics. Confidential: per-account orders, amounts, fees, costs, margin and shop identifiers. Restricted: OAuth tokens, integration secrets, database credentials and MFA secrets. Each class has its own handling rule: confidential data is isolated per organisation, and restricted material is never exposed in a user interface, a log line or an export.
3. Encryption
In transit: HTTPS with TLS 1.2 and TLS 1.3 only; TLS 1.0 and 1.1 are refused during the handshake, and the configured suites are AEAD (ECDHE-AES-GCM and CHACHA20-POLY1305). All HTTP traffic is redirected (301) to HTTPS. At rest: OAuth tokens, integration payloads and MFA secrets are encrypted with AES-256-GCM; passwords are never stored in plaintext — per-user salted scrypt with constant-time comparison. Production keys and secrets live in a root-readable file and are not committed to the code repository. Disclosed limitation: the operating-system volume does not use customer-managed full-disk encryption; compensating controls are cloud-level isolation, key-only human access to the host, and application-layer encryption of everything classified as restricted.
4. Access control and least privilege
Authentication enforces a password policy (minimum 12 characters, with per-account expiry), TOTP multi-factor authentication with step-up re-authentication before sensitive actions, server-validated sessions with idle expiry, HttpOnly + Secure + SameSite=Lax cookies, and server-side revocation on logout, logout-all and password reset. Roles are scoped per organisation (owner, admin, member); destructive privacy actions require the owner role. Every marketplace data query is keyed by the organisation derived from the validated session — a client-supplied identifier is never trusted. Human access to production is limited to the operator, over SSH with key authentication (password authentication is disabled in sshd). At the database layer, the application connects with a dedicated non-administrative service role and backup dumps run under a read-only role; database credentials live in a root-only file.
5. Network segregation and perimeter protection
Nginx on ports 80 and 443 is the single public entry point; the cloud security list allows only 22, 80 and 443 inbound from outside, and internal application and database ports are unreachable from the internet (external verification: ports 3001, 3004, 3006, 3008, 5432, 6380, 8001 and 8443 did not answer). PostgreSQL listens on 127.0.0.1 only. Active host protections: Fail2ban (sshd jail), ClamAV with daily signature updates, Suricata in observation mode, and response headers x-frame-options DENY, x-content-type-options nosniff, referrer-policy strict-origin-when-cross-origin and a permissions-policy that disables camera, microphone and geolocation. Sensitive routes are rate-limited, and mutating browser requests are origin-checked.
6. Security baseline for daily operations
This is the baseline required of anyone operating the service, measured by command rather than declared: a corporate, domain-authenticated workstation with endpoint anti-malware running in real time (real-time, on-access, behaviour and network protection plus tamper protection enabled), the system firewall active on all three profiles, an enforced password and lockout policy, and a console that requires a credential at logon (no automatic logon). Absolute rule: no production credential and no customer personal data on any laptop or workstation — credentials exist only in a root-only file on the server, and restricted data exists only encrypted in the database. Clean desk for material containing customer data. Disclosed limitation: on that endpoint we do not configure an automatic inactivity screen lock, full-disk encryption or a dedicated password manager — it is an organisation-managed machine and those three decisions belong to corporate IT; the compensating control is that it holds neither personal data nor production secrets. Two-factor authentication is mandatory in the product (TOTP with step-up re-authentication before sensitive actions, section 4) and is stated by the responsible operator to be enabled on the accounts that unlock production, because the code host's API no longer exposes that verification by command. On the server the baseline is verifiable: key-only SSH, an unprivileged service user, a root-only environment file for the service, and automatic security patching.
7. Vulnerability management
Automated patching of distribution security repositories and maintained extensions (unattended-upgrades enabled), daily antivirus signature updates, dependency vulnerability scanning in continuous integration with a blocking threshold on high-severity findings, and quality gates before any deploy (type check, lint and the full test suite). A monthly maintenance window applies complete upgrades and a host reboot when the kernel requires it; outstanding patches are tracked as dated debt rather than a permanent exception.
8. Logging, monitoring and detection
Structured JSON logs with severity levels, a database audit trail for security and privacy events, proxy log rotation (14 periods, compressed) and system journal retention, and health monitoring through /api/health, /api/health/live, /api/health/ready and the public /status page. Marketplace synchronisation failures are classified, recorded and surfaced in the seller interface, with e-mail and WhatsApp alerts according to each account's configuration.
9. Incident response
A written plan with four severity classes and seven stages (detection, triage, containment, eradication, recovery, communication, post-incident), a named incident lead per the responsibility matrix, evidence preservation for at least 12 months with UTC timestamps, and notification to the affected marketplace partner within 24 hours of confirmation — without waiting for the investigation to close. Channels: [email protected] for privacy and data-subject matters, the affected partner's support/Partner Center channel for marketplace data, and the partner's security address where applicable. At least one tabletop exercise per half-year, with results recorded.
10. Data subject rights and seller tools
Authenticated export of account data (POST /api/privacy/export, with secrets redacted) and an owner-only deletion/anonymisation request (POST /api/privacy/delete-request, which anonymises the record, revokes every session and writes an audit event). Data Protection Officer contact: [email protected] — target response time: 15 days.
11. Retention and deletion
Account data: while the account is active and, where applicable, up to 5 years for fiscal or legal obligations. Operational logs: typically 12 months. Marketplace data: while the integration/account remains active and within plan history limits; removed or anonymised through the deletion workflow. OAuth tokens: while the integration is connected; rotated or revoked on disconnect or during an incident. Cancellation does not delete the account: data stays until the owner requests deletion, and is then removed or anonymised, except where tax law requires retention.
12. Availability and backup
Nightly logical database dump (02:00 UTC, 30-day retention) and an application backup at every deploy (14-day retention), with restoration covered by the incident response plan. The deploy script preserves the previous build and runs post-deploy health checks. In progress, and disclosed: copying database dumps to a second location outside the production host.
13. Third parties that process data
Oracle Cloud Infrastructure (application and database hosting, São Paulo region, Brazil), the payment processor Stripe (Syntra subscriptions only — no marketplace order data passes through it, and Syntra does not store card numbers), and notification delivery providers (e-mail and WhatsApp). Third-party processing is limited to what the service requires.
14. Use of marketplace data
Syntra processes API and webhook data only to deliver the service the seller contracted (order import, margin, reconciliation, repricing and alerts). We do not sell personal data and we do not use TikTok Shop or any other marketplace data for advertising or for profiling unrelated to the service.
15. Review
This plan is reviewed at least semi-annually and after material incidents. Current version: 1.4 — October 2026.
