Skip to main content

​
Supported Versions

VersionSupported
0.x Yes
Security patches will be applied to the latest release in the supported range. Users are encouraged to stay on the latest version.

​
Reporting a Vulnerability

Please do NOT open a public GitHub issue for security vulnerabilities.
If you discover a security vulnerability in @vaultsaas/core, please report it responsibly by emailing: [email protected]

​
What to Include

Your report should include as much of the following as possible:
A clear description of the vulnerability and how it could be exploited.
Detailed steps to reproduce the issue, including any required setup or configuration.
Which versions of the SDK are affected by this vulnerability.
Your assessment of the impact (e.g., data exposure severity, authentication bypass scope).
Any proof-of-concept code or logs, if available.
A suggested fix, if you have one.

​
Response Timeline

1

Acknowledgment

Within 48 hours of your report
2

Initial assessment

Within 5 business days
3

Critical fixes

Released within 7 days of confirmation
4

Non-critical fixes

Released within 14 days of confirmation
We will keep you informed of our progress throughout the process and credit you in the release notes (unless you prefer to remain anonymous).

​
Scope

​
In-Scope Security Issues

The following are considered in-scope security issues for this project:
  • Authentication or authorization bypass (e.g., API key handling flaws)
  • Sensitive data leaks (e.g., payment credentials, API keys exposed in logs or errors)
  • Injection vulnerabilities (e.g., request parameter injection, header injection)
  • Webhook signature verification bypass
  • Insecure default configurations that could lead to data exposure
  • Dependency vulnerabilities that are directly exploitable through the SDK
  • Cryptographic weaknesses in signature verification or token handling

​
Out of Scope

The following are considered out of scope:
  • Social engineering attacks against VaultSaaS maintainers or users
  • Denial-of-service attacks against a user’s own infrastructure
  • Vulnerabilities in third-party payment providers (e.g., Stripe, PayPal) — report those directly to the provider
  • Issues that require physical access to a user’s machine
  • Attacks that require the attacker to already have valid API credentials
  • Vulnerabilities in applications built with the SDK that are caused by the application’s own code (e.g., improper secret storage)
  • Best-practice recommendations that do not represent an exploitable vulnerability

​
Disclosure Policy

We follow a coordinated disclosure process:
1

Private submission

The reporter submits the vulnerability privately.
2

Confirmation

We confirm and assess the issue.
3

Fix development

We develop and test a fix.
4

Release

We release the fix and publish a security advisory.
5

Public disclosure

The reporter is free to publish details after the fix is released.
We ask that you allow us a reasonable amount of time to address the issue before public disclosure.

​
Recognition

We value the security research community and are happy to acknowledge your contribution. With your permission, we will credit you by name (or handle) in:
  • The relevant release notes in CHANGELOG.md
  • The GitHub security advisory
If you prefer to remain anonymous, we will respect that preference.

​
Latest Security Review

​
Release 0.1.0 Security Hardening

Date: March 2, 2026 Scope: Webhook signature verification and configuration validation hardening.

​
Reviewed Areas

Signature Verification

  • Shared signature utilities (createHmacDigest, secureCompareHex, raw payload handling)
  • Stripe webhook verification (signature parsing, timestamp replay window, HMAC verification)
  • dLocal webhook verification (signature header validation and HMAC verification)
  • Paystack webhook verification (signature header validation and HMAC verification)

Configuration Validation

  • VaultClient configuration validation for provider, routing, logging, idempotency, and platform config
  • Provider config static capability declarations

​
Key Findings

Timing-safe comparison is used for signature validation to prevent timing attacks.
Stripe replay protection is enforced with a 5-minute timestamp tolerance.
Missing/malformed signature headers fail closed, preventing bypass attacks.
Invalid JSON webhook payloads fail closed after signature checks.
Provider config now requires static capability declarations (supportedMethods, supportedCurrencies, supportedCountries) for routing validation.

​
Residual Risk Notes

  • dLocal and Paystack webhook verification do not include provider timestamp replay checks in current adapter implementations.
  • Integrators should terminate TLS at trusted edges and enforce ingress protections (IP allowlists/WAF) for webhook endpoints.

​
Test Evidence Added

  • Expanded negative-path webhook tests for Stripe, dLocal, and Paystack
  • Expanded config-validation tests for missing static adapter metadata
  • Expanded provider error-classification tests for network/auth/rate-limit/invalid-request/fraud/auth-required cases

​
Contact

For any security-related questions or concerns, reach out to [email protected].

Build docs developers (and LLMs) love

Get started for freeTalk to us