Bridgelet is committed to maintaining the security of our infrastructure SDK and protecting users who rely on our ephemeral account system for Stellar payments. Given the financial nature of our platform, we take security vulnerabilities seriously and appreciate the security community's efforts in responsibly disclosing issues.

This document outlines our security practices, how to report vulnerabilities, and what to expect from our security response process.

We provide security updates for the following versions:

Note: As we are in early development (Q1 2026 MVP phase), security patches will be applied to the main branch and released as soon as possible. Once we reach stable releases, we will maintain security support for the current major version and one prior major version.

If you discover a security vulnerability in Bridgelet, please report it responsibly by emailing:

📧 Security Contact: aminubabafatima8@gmail.com

Please DO NOT:

• Open a public GitHub issue for security vulnerabilities
• Disclose the vulnerability publicly before we've had a chance to address it
• Exploit the vulnerability beyond what is necessary to demonstrate the issue

To help us understand and address the issue quickly, please include:

1. Description: Clear explanation of the vulnerability
2. Impact: Potential security impact and affected components
3. Reproduction Steps: Detailed steps to reproduce the issue
4. Proof of Concept: Code, screenshots, or logs demonstrating the vulnerability
5. Suggested Fix: (Optional) Your recommendations for addressing the issue
6. Environment Details:
   • Affected repository (bridgelet-core, bridgelet-sdk, or bridgelet-ui)
   • Version or commit hash
   • Network (Stellar Testnet/Mainnet)
   • Any relevant configuration details

We are committed to responding promptly to security reports:

Note: These are target timelines. Complex issues may require additional time, and we will keep you informed throughout the process.

We classify vulnerabilities using the following severity levels:

• Critical: Immediate risk of fund loss, unauthorized access to accounts, or complete system compromise
• High: Significant security impact affecting multiple users or core functionality
• Medium: Limited security impact with mitigating factors or requiring specific conditions
• Low: Minimal security impact or theoretical vulnerabilities

Security issues in the following areas are within scope:

• Fund sweep logic vulnerabilities
• Account restriction bypass
• Time-lock manipulation
• Authorization flaws
• Reentrancy or other contract exploits

• Authentication and authorization issues
• API security vulnerabilities
• Cryptographic implementation flaws
• Private key management issues
• Database security concerns
• Dependency vulnerabilities

• Deployment security misconfigurations
• Secret management issues
• Network security concerns

• Analytics identifiers and payloads produced by the frontend, as defined in docs/analytics-spec.md
• The localStorage-persisted anonymous_id and the sessionStorage session_id: their generation, retention, and erasure
• Claim-derived values that appear in analytics payloads (claim_id, amount_usd_equiv) and any risk of the claim token — a bearer credential — reaching an analytics store
• The Do Not Track (DNT: 1) opt-out path, including the guarantee that no identifier is minted for a visitor who opted out
• Keeping third-party analytics scripts off /claim/[token] so the claim token is not leaked via Referer

The following are generally out of scope:

• Social engineering attacks against Bridgelet team members
• Physical attacks against infrastructure
• Denial of Service (DoS) attacks
• Issues in third-party dependencies (report these to the respective maintainers)
• Vulnerabilities requiring physical access to user devices
• Issues already known and documented in our issue tracker
• Theoretical vulnerabilities without practical exploit scenarios

Bridgelet implements a multi-layered security approach:

1. Single-Use Accounts: Ephemeral accounts are designed for one-time use, minimizing exposure
2. Restricted Transfers: Smart contract enforced destination locking
3. Time-Based Expiration: Automatic fund recovery for unclaimed accounts
4. No Seed Phrase Exposure: Recipients don't handle sensitive cryptographic material
5. Claim Authentication: Secure verification before fund release

For detailed information about our security architecture, threat model, and security assumptions, please refer to our Security Model Documentation.

Analytics data is part of the product's security posture, not an auxiliary concern. The frontend stores an anonymous_id in localStorage and a session_id in sessionStorage, and emits event payloads that can include claim_id and amount_usd_equiv. Because the claim token is a bearer credential (docs/analytics-server-vs-client-decision.md §4.2), how it is handled in payloads and how long analytics data is kept are security-relevant decisions.

Controls, and the documents that record their current status:

The localStorage exposure audit and its checklist are the standing review tool for this class of concern and must be re-run whenever what the frontend persists changes. Analytics-specific vulnerabilities — for example a payload that leaks the claim token to a third-party script, or a bypass of the DNT opt-out — are in scope for security reports.

We follow a coordinated disclosure process:

1. Private Disclosure: You report the vulnerability privately to our security team
2. Investigation: We investigate and develop a fix
3. Fix Development: We create and test a security patch
4. Release: We deploy the fix to production and release updated versions
5. Public Disclosure: After the fix is deployed, we publish a security advisory
6. Credit: We acknowledge your contribution (if desired)

• We aim to resolve and disclose vulnerabilities within 90 days of the initial report
• If you plan to publicly disclose the vulnerability, please give us at least 90 days notice
• We may request an extension if the issue is particularly complex
• We will work with you to coordinate the disclosure timeline

Analytics is in scope for this policy. The product handles wallet addresses, payment amounts and claim tokens, so "we only collect analytics" is not a neutral statement.

What the reference apps collect. Interaction events carrying a §3.1 base payload: a randomly generated anonymous_id, a per-visit session_id, a coarse device_type, app_version, network, and a UTC timestamp. Some events additionally carry a claim_id and an amount_usd_equiv. Full field list: docs/analytics-spec.md §3.1–§3.2.

What is never collected. Wallet addresses (public or secret), claim tokens, private or secret keys, message contents, recipient names or email addresses. A wallet address would identify a third party; a claim token is a bearer credential for the funds. Two consequences follow and are enforced in code:

• The claim page loads no third-party script or asset, so a claim token cannot leak via Referer (docs/security-model.mdx, T-16).
• An explorer link is rendered only when a real transaction hash is available. A claim token or account id in a /tx/ URL resolves to nothing and would hand a bearer credential to a third party, so no link is rendered instead.

Storage. The identifiers live in browser storage only (localStorage / sessionStorage on web, AsyncStorage on mobile) and are not sent to the SDK. No claim token is ever persisted. Any change to what is written to browser storage must pass bridgelet-product-audit/checklists/localstorage-data-exposure-checklist.md before merge.

Opting out. A visitor's browser Do Not Track signal suppresses every event and no identifier is minted; an explicit on-site opt-out suppresses everything independently of browser settings. Note that opted-out visitors record nothing, so any published usage figure is a lower bound.

Reporting. Vulnerabilities in analytics collection or in the identifiers are security reports under this policy — report them to the contact below, not as a public issue.

If you're integrating Bridgelet into your application:

1. Keep Dependencies Updated: Regularly update to the latest stable versions
2. Secure Key Management: Use hardware security modules (HSMs) or secure key management services for production keys
3. Environment Isolation: Separate development, staging, and production environments
4. Monitor Transactions: Implement monitoring and alerting for unusual account activity
5. Rate Limiting: Implement rate limiting on claim endpoints
6. Audit Logs: Maintain comprehensive audit logs for all account operations
7. Network Security: Use HTTPS/TLS for all API communications
8. Input Validation: Validate all inputs, especially Stellar addresses and amounts

If you're contributing to Bridgelet:

1. Code Review: All code changes require security-focused review
2. Dependency Scanning: Run dependency vulnerability scans before submitting PRs
3. Test Coverage: Include security test cases for new features
4. Secrets Management: Never commit secrets, keys, or credentials to the repository
5. Follow Guidelines: Adhere to secure coding practices outlined in CONTRIBUTING.md
6. Analytics & client-side data: Follow docs/analytics-spec.md for payload shape and privacy rules, and check docs/localstorage-data-exposure-audit.md when you add or change persisted client state

• Deploy contracts with multi-signature authorization for critical operations
• Use time-locks for administrative functions
• Implement circuit breakers for emergency situations
• Conduct thorough testing on Testnet before Mainnet deployment

• Enable all security headers (HSTS, CSP, X-Frame-Options, etc.)
• Use environment variables for sensitive configuration
• Implement request signing for API authentication
• Enable audit logging for all financial operations
• Configure appropriate CORS policies

• Use principle of least privilege for all service accounts
• Enable encryption at rest and in transit
• Implement network segmentation
• Regular security patching and updates
• Enable monitoring and alerting

As we approach production readiness, we plan to:

• Conduct professional smart contract audits
• Perform penetration testing on the SDK and infrastructure
• Engage with the Stellar security community for peer review
• Publish audit reports and findings

Current Status: Pre-audit phase (MVP development)

We are currently evaluating the establishment of a bug bounty program. Details will be announced as we approach production release.

Security advisories and updates will be published through:

• GitHub Security Advisories
• Release notes with security tags
• Direct notification to known integrators
• Stellar community channels

Subscribe to repository notifications to stay informed about security updates.

Security Email: aminubabafatima8@gmail.com

General Contact:

• Issues: GitHub Issues (non-security issues only)
• Discussions: GitHub Discussions

We would like to thank:

• The Stellar security community for their guidance
• Security researchers who responsibly disclose vulnerabilities
• Open source security tools and frameworks that help us maintain security

Our security practices are informed by:

• OWASP Top 10
• CWE/SANS Top 25 Most Dangerous Software Errors
• Stellar Security Best Practices
• Smart Contract Security Best Practices

This security policy is licensed under CC BY 4.0.

Last Updated: October 17, 2026

Thank you for helping keep Bridgelet and our users safe! 🔒