1. Security model
DocxAPI uses a focused conversion service with authenticated generation endpoints. Production is deployed in containers behind a reverse proxy. Application data and authentication are handled through Supabase; payments are handled by Stripe. Public health information is deliberately limited.
2. Document processing
- Pandoc conversion runs in sandbox mode.
- Remote-resource access is disabled during conversion, reducing server-side request forgery exposure.
- Input size, output size, execution time, queue capacity, and concurrent conversions are bounded.
- Temporary working files are cleaned after binary/Base64 responses and after failures.
- Temporary URL outputs expire after the configured period, currently 24 hours, and are removed by cleanup routines.
- Filenames are normalized before use and response headers safely encode Unicode names.
3. Authentication and credentials
Dashboard sessions use Google OAuth through Supabase. API requests use secret API keys. Stored API-key values are one-way hashes; the raw key is disclosed only when it is created or rotated. Plan-specific key limits and server-side authorization are enforced by the backend. Profiles marked inactive cannot authenticate.
Customers should keep keys in a secret manager or n8n credential, rotate suspected keys immediately, avoid embedding keys in browser code, and use a separate key per environment where their plan permits it.
4. Application protections
- Schema validation runs before generation.
- Rate limits identify authenticated traffic by hashed API key.
- Request IDs support incident tracing without exposing raw keys.
- Security headers include content-type protection, frame denial, referrer control, and restrictive browser permissions.
- HTML inserted into dashboard views is escaped where user-controlled labels and domains appear.
- Dependency auditing and automated tests run in CI, together with the production Docker build.
- Graceful shutdown protects active work during deployment.
5. Usage and billing integrity
Generation credits are reserved and finalized through transactional database operations. Concurrent reservations count toward the available allowance. Failed conversions release reserved bonus credit. Stripe webhook events are claimed and completed idempotently, and transient failures return an error so Stripe can retry.
Card details are collected and processed by Stripe and are not stored by DocxAPI.
6. Operational boundaries
No internet service is risk-free. Current priorities include shared object storage for temporary downloads in multi-replica deployments, ongoing dependency updates, retention review, backup governance, and periodic concurrency and recovery testing. Custom templates are not currently accepted, which reduces the document-processing attack surface.
7. Responsible disclosure
If you believe you found a vulnerability, email security@searchops.com.br with the affected endpoint, reproduction steps, impact, and any supporting request IDs. Do not access other users' data, disrupt production, perform denial-of-service testing, or publicly disclose an unresolved issue. We will acknowledge a good-faith report and coordinate next steps.