We take the security of our customers and their data seriously. Bountiful Apps is a Florida DBA owned by SM Carlson, LLC, and this page explains how to report a vulnerability, what you can expect from us in return, and the practices we follow across our products.
Reporting a vulnerability
If you believe you’ve found a security issue in this website or any Bountiful Apps product, please use the contact form on this site and clearly note that the report is security-related. If the finding is sensitive, share only the minimum needed to establish contact first, and we’ll coordinate a safer follow-up channel. Please include:
- A clear description of the issue and its potential impact
- Steps to reproduce, including any relevant URLs, payloads, or accounts used
- Your name or handle (if you would like credit) and preferred contact method
We aim to acknowledge reports within 2 business days and keep you updated as we investigate. We don’t run a formal bug bounty program today, but we’re genuinely grateful for responsible disclosure and will credit researchers publicly (with permission) for meaningful findings.
Safe harbor for good-faith research
We will not pursue or support legal action against researchers who:
- Make a good-faith effort to avoid privacy violations, service degradation, or data destruction
- Only interact with accounts and data they own, or have explicit permission to test
- Give us reasonable time to investigate and remediate before public disclosure
- Do not attempt to extort, threaten, or otherwise misuse what they find
Practices we follow
- Encryption. All traffic to our sites and APIs is served over TLS. Sensitive customer data is encrypted at rest in our databases.
- Access control. Production access is limited to a small number of team members using hardware-backed multi-factor authentication.
- Least privilege. Services and people get the minimum access they need to do their jobs, reviewed on a regular cadence.
- Dependency hygiene. We track third-party dependencies, apply security patches promptly, and remove libraries we no longer need.
- Backups. Customer-impacting systems are backed up on a regular schedule, and we periodically verify those backups.
- Code review. Meaningful changes are reviewed before they reach production.
Things that are out of scope
A few common-but-low-impact reports we generally decline unless combined with a real impact path:
- Missing best-practice HTTP headers with no demonstrated exploit
- Self-XSS requiring the user to paste attacker code into their own browser
- Automated scanner output without a concrete attack scenario
- Email spoofing reports that don’t result in a credible phishing path
Contact
For security issues, privacy requests, or data-access questions, use the contact form on this site and include enough detail for us to route your request correctly.