SOAPless
Sign Up

Security

How we protect your data and credentials at every layer.

Security is fundamental to SOAPless. As a proxy that handles your SOAP service credentials, we recognize the critical importance of protecting your data. This page describes the technical measures we currently implement to protect your information. It describes operational practices, not a certification or service-level guarantee.

Encryption at Rest

SOAP Credentials — AES-256-GCM

All SOAP service credentials (usernames, passwords, WS-Security tokens) are encrypted using AES-256-GCM before being stored in our database. Each credential record uses a unique initialization vector (IV) and produces an authentication tag to ensure both confidentiality and integrity.

Encryption keys are managed separately from the database and are used only for application-side encryption and decryption. Credentials are decrypted only at the moment of proxying a request to the upstream SOAP service and are never written to logs or temporary storage in plaintext.

API Keys — SHA-256 Hashing

API keys are hashed using SHA-256 before storage. The full API key value is displayed to you only once at creation time. When you make an API request, we hash the provided key and compare it against the stored hash. This means that even in the event of a database compromise, your API keys cannot be recovered.

Database Security

Row Level Security (RLS)

All database tables use Supabase Row Level Security policies. Every query is automatically scoped to the authenticated user's data. This means that even if an application-level bug occurs, the database layer prevents one user from accessing another user's data.

RLS policies are defined declaratively and reviewed as part of every schema change. Service role access is restricted to server-side operations only and is never exposed to client-side code.

Transport Security

HTTPS / TLS Everywhere

Client-facing SOAPless properties are served over HTTPS. For upstream SOAP traffic, transport protection depends on the registered endpoint: if the upstream service uses HTTPS, traffic between SOAPless and that upstream service is protected in transit by TLS.

If an upstream SOAP endpoint is HTTP-only, transport encryption is not added by the proxy layer itself, and customers should assess that upstream risk before using it in production.

No SOAP Body Logging

SOAPless does not log, store, or inspect the content of SOAP request or response bodies passing through our proxy. Only the following metadata is recorded for analytics and debugging:

  • Timestamp of the request
  • SOAP operation name
  • HTTP status code returned
  • Response latency (milliseconds)
  • Service identifier
  • Error type classification (if applicable)
  • Truncated, sanitized error message (if applicable)

Error messages from SOAP faults are truncated to 200 characters and sanitized to remove potential personal data before storage. Request and response bodies are never logged.

Dependency Security

We perform regular dependency audits using npm audit and routine dependency review during development. We aim to keep a minimal dependency footprint and address material vulnerabilities in a reasonable timeframe based on severity and available mitigations.

Infrastructure Security

  • Application hosting and edge delivery rely on managed platform controls provided by Vercel.
  • Database hosting and authentication rely on managed controls provided by Supabase.
  • Environment variables and secrets are stored in encrypted vaults and never committed to version control.
  • Production changes are reviewed through our deployment workflow before release.

Responsible Disclosure

We value the work of security researchers and encourage responsible disclosure of vulnerabilities. If you discover a security issue, please report it to:

Email: hello@soapless.miravy.com

Please include:

  • A description of the vulnerability and its potential impact;
  • Steps to reproduce the issue;
  • Any supporting evidence (screenshots, logs, proof of concept).

We review good-faith reports and aim to acknowledge receipt promptly. We will not pursue legal action against researchers who act in good faith, avoid user harm, and follow this disclosure process.

Compliance and Standards

  • Data processing designed with GDPR principles in mind. Data Processing Agreements available on request for enterprise customers.
  • We do not sell personal information. California residents can contact us to exercise their CCPA rights.
  • Regular dependency vulnerability scanning via npm audit.