Security Policy

Report a vulnerability

Email security@sendx.io or security@sendworks.com. Both reach the same team.

We aim to acknowledge every report within 2 business days and give you a triage decision within 10 business days.

Our promise to you (safe harbor)

We want security researchers to feel safe reporting to us. So:

We'll consider your research authorized if you make a good-faith effort to follow this policy. For inadvertent, good-faith violations, we won't pursue civil action against you or refer you to law enforcement. This authorization is meant to line up with good-faith security research as described in current US Department of Justice policy under the Computer Fraud and Abuse Act (CFAA).

This policy is a commitment from us to good-faith researchers. It doesn't authorize you to break the law, and it can't waive rights held by third parties. If a third party brings action against you for work that followed this policy, we'll confirm, on request, that your research was authorized under it.

If you're ever unsure whether something is allowed, stop and ask us first at the address above. We'd rather answer a question than see you cross a line by accident.

This safe harbor applies only to activity that stays inside this policy. It does not cover the actions listed under "What voids safe harbor" below.

Scope

In scope

• app.sendx.io and the SendX application
• api.sendx.io and the SendX API
• app.sendpost.io and the SendPost application
• api.sendpost.io and the documented SendPost email API (including the SendGrid-compatible and SES-compatible endpoints)
• SendX-hosted customer subdomains (*.sendx.io), but only the shared SendX infrastructure behind them: the forms, endpoints, and sending logic we operate. A customer's own content, list, or account data is not your target, and testing it is out of scope.
• Authentication, session handling, and access-control logic on the above
• Anything that lets one account or sub-account reach another account's data or sending

Out of scope

• Marketing sites, blogs, docs sites, and status pages
• Third-party services we use but don't control (payment processors, analytics, CDNs, ISPs, blacklist providers)
• Any SendX or SendPost account you don't own or haven't been given written permission to test
• Physical attacks, and anything targeting our staff, offices, or hardware
• Denial of service, load testing, or anything that degrades service for other customers

If you're not sure whether an asset is in scope, ask before you test it.

Rules of engagement

1. Only test accounts you own. Create your own free account to test against. Never touch another customer's data.
2. Prove the bug with the lightest possible touch. One record, one screenshot, one request. Don't pull data at scale to "prove impact." A single row is enough.
3. If you stumble onto personal data, stop. Don't view more, don't download it, don't save it. Tell us right away. We have legal duties around personal data, and your restraint protects both our customers and you.
4. Don't run automated scanners against production in a way that generates load or noise. Manual validation only.
5. Give us a reasonable chance to fix it before you tell anyone else. See "Disclosure" below.
6. One issue per report, with clear steps to reproduce. If several bugs share one root cause, that's one issue.

What we're looking for

High-value findings for a platform like ours are things that break the wall between accounts, expose customer data, or let someone send email they shouldn't. Missing a rate limit on an email-sending endpoint that lets someone flood a third party's inbox from our systems is in scope, because it abuses our sending reputation and our users. Pure "take the site down with load" testing is not.

When you test for a missing rate limit, prove it against an inbox you control, not a stranger's. A short burst of repeated requests that shows no throttle, CAPTCHA, or cooldown kicks in is enough to demonstrate the gap. Don't actually flood a third party to make the point.

What voids safe harbor (and any reward)

These aren't security research. If you do any of them, this policy no longer protects you, and for the last two we will involve law enforcement:

• Accessing, copying, downloading, altering, or keeping data that belongs to another user
• Degrading or disrupting the service for other customers
• Publicly disclosing a vulnerability, or details of one, before we've fixed it and agreed a date with you
• Demanding payment as a condition of telling us about a bug, or refusing to share details until we pay
• Threatening to disclose, sell, leak, or exploit a bug or any data

To be clear on the last two: a reward is something we choose to pay after you report a valid bug in good faith. It is never a ransom. If your first message names a price before you've shown us the issue, or carries a threat, we treat it as an extortion attempt, not a report.

Rewards

We offer rewards as a thank-you for valid, in-scope, previously unknown vulnerabilities, reported in good faith and confirmed by our team.

Rewards are discretionary and recognition-first. Every valid report earns a credit on our security acknowledgments page if you'd like one. Reports that carry real security impact may also earn a cash reward.

We decide each reward by rating the severity of the finding. We use CVSS as a starting point, then adjust for the real-world impact on our platform and customers. We set the severity. A high score on something with no real-world impact may earn less. A clever chain of lower-severity bugs that reaches customer data may earn more.

We're a small, bootstrapped company, and we size rewards accordingly. We are under no obligation to pay a reward for any given report.

By accepting a reward, you agree not to publicly disparage us over a report we've resolved, and not to release the technical details of a vulnerability before the date we agree. You're always free to say that you found and reported a bug once we've agreed timing.

Eligibility

To qualify for a reward, a report must:

• Describe a real, reproducible security vulnerability
• Fall within the scope above
• Be new to us. The first complete report of an issue wins. Later duplicates don't qualify.
• Follow every rule in this policy, including no access to, copying of, or exfiltration of other users' data

We validate and, where needed, fix the issue before we pay.

How we pay

We treat rewards like any other contractor payment. Before we can pay, we need three things from you:

1. A tax form. US persons and businesses: a completed W-9. Researchers outside the US: a W-8BEN (individual) or W-8BEN-E (entity).
2. A matching payee. The receiving account must be in your own name, or your registered business name, and must match your tax form. We don't pay anonymous parties or third-party accounts.
3. An invoice showing your name or business, address, and the report reference number.

Payments are processed in USD via ACH transfer for US-based researchers and via PayPal for international researchers. Any alternative payment methods are at the sole discretion of the company.

If we pay a US person or unincorporated business $600 or more in a calendar year, we'll issue a Form 1099-NEC, as US tax law requires.

We can't make payments to any individual or entity on US sanctions lists (OFAC), or located in a sanctioned region.

When we don't pay

We won't issue a reward, and safe harbor won't apply, if:

• The report is out of scope, a duplicate, or already known to us
• You accessed, copied, downloaded, or retained data belonging to other users
• You publicly disclosed the issue before we fixed it, or before a date we agreed with you
• You demanded payment as a condition of disclosing the vulnerability, or attached any threat to disclose, exploit, sell, or leak it. That falls outside this policy, voids any reward and safe harbor, and may be reported to law enforcement.

Out-of-scope report types (we won't reward these)

These come in constantly from automated tools. They're almost never a real risk on their own, so we don't reward them unless you can show a working exploit with real impact:

• Missing security headers (CSP, HSTS, X-Frame-Options) with no demonstrated exploit
• Missing or "weak" SPF, DKIM, or DMARC records
• Self-XSS that needs the victim to paste code into their own console
• Output from an automated scanner (Nessus, Burp, Acunetix, Nuclei, and the like) with no manual validation and no proof of concept
• AI-generated reports with no human verification
• Denial of service, brute force, or volumetric testing
• Social engineering, phishing, or physical attacks
• Clickjacking on pages with no sensitive action
• "Your software is out of date" with no working exploit
• Username or email enumeration with no clear impact
• Bugs that only work in unsupported or end-of-life browsers

Disclosure

We practice coordinated disclosure. Once we've confirmed a bug, we'll work on a fix and keep you posted. Please don't disclose it publicly until we've fixed it and agreed a date with you. Once it's fixed, we're glad to agree that date, and we'll credit you on our security acknowledgments page if you'd like.

Questions

Email security@sendx.io. We read every message.