Security Policy
Vulnerability Disclosure Program
At Create State, we take security seriously. We appreciate the work of security researchers who help us keep our platform and users safe. This policy describes how to report security vulnerabilities to us and what you can expect from us in return.
Safe Harbor
We will not pursue legal action against security researchers who report vulnerabilities in good faith and follow this policy. Specifically:
- - We consider security research conducted under this policy to be authorized
- - We waive any related claims under the Computer Fraud and Abuse Act (CFAA)
- - We will work with you to understand and resolve the issue quickly
- - If legal action is initiated by a third party, we will make clear that your actions were authorized
This safe harbor applies only when you follow the guidelines in this policy. Testing that falls outside this policy (such as accessing other users' data, causing service disruption, or social engineering) is not authorized and may be subject to legal action.
1 How to Report a Vulnerability
Please report security vulnerabilities via email to:
For sensitive reports, you may encrypt your message using our PGP key (coming soon - contact us for details).
What to Include in Your Report
- - Description: The vulnerability and its potential impact
- - Steps to reproduce: As detailed as possible
- - Affected areas: URLs, parameters, or components
- - Proof of concept: Code, screenshots, or video if applicable
- - Contact information: Email at minimum
- - Remediation suggestions: Optional but appreciated
2 What to Expect From Us
When you report a vulnerability, here's what you can expect:
- Within 3 days: We will acknowledge receipt of your report
- Within 10 days: We will provide an initial assessment and expected timeline
- Ongoing: We will keep you informed of our progress and notify you when the issue is resolved
We aim to resolve critical vulnerabilities within 7 days and high-severity issues within 30 days. Complex issues may take longer, and we will keep you updated on our timeline.
3 Scope
The following systems and services are in scope for security research:
In Scope
- - All Create State web properties and APIs
- - Official Create State SDKs and client libraries
- - Authentication and authorization systems
- - Payment processing flows
- - Data storage and retrieval
Out of Scope
- - Third-party services and infrastructure providers
- - Physical security of our offices or data centers
- - Social engineering attacks against our employees
- - Email systems (phishing, spoofing)
4 Rules of Engagement
To qualify for safe harbor protection, you must:
- - Only test against your own accounts: Create test accounts, don't access other users' data
- - Avoid service disruption: No DoS/DDoS attacks or actions that degrade service for others
- - Don't exploit vulnerabilities: Only demonstrate what's necessary to show the issue
- - Don't access or modify data: Only interact with data that belongs to you
- - Don't perform social engineering: No targeting of our employees or users
- - Keep findings confidential: Wait until we've had reasonable time to fix the issue
- - Report vulnerabilities promptly: Don't stockpile them
Prohibited Actions
The following activities are strictly prohibited and are not covered by our safe harbor:
- - Denial of service attacks (DoS/DDoS)
- - Automated vulnerability scanning that generates excessive traffic
- - Accessing, downloading, or modifying data belonging to other users
- - Sending unsolicited messages to users (spam, phishing)
- - Physical attacks or threats
- - Attempting to access non-public internal systems
- - Publicly disclosing vulnerabilities before they are fixed
5 Qualifying Vulnerabilities
We're particularly interested in vulnerabilities that could:
- - Compromise user accounts or authentication
- - Access or expose sensitive user data
- - Execute arbitrary code on our systems
- - Bypass authorization controls
- - Inject malicious content (XSS, SQL injection, etc.)
- - Expose API keys, secrets, or credentials
- - Compromise the integrity of user data or code
Non-Qualifying Issues
The following are generally not considered security vulnerabilities for the purposes of this program:
- - Missing security headers that don't lead to exploitable vulnerabilities
- - Clickjacking on pages without sensitive actions
- - Self-XSS (attacks that require the victim to paste code into their own browser)
- - CSRF on logout or other non-sensitive actions
- - Username/email enumeration (unless combined with other vulnerabilities)
- - Software version disclosure
- - Theoretical vulnerabilities without proof of concept
- - Reports from automated scanners without manual verification
6 Recognition
We value the contributions of security researchers. While we do not currently operate a paid bug bounty program, we offer the following recognition for valid vulnerability reports:
- - Hall of Fame - With your permission, we will acknowledge your contribution on our security acknowledgments page
- - Reference Letter - Upon request, we can provide a reference letter confirming your responsible disclosure
- - Swag - For significant findings, we may send Create State merchandise as a thank-you
We are considering implementing a paid bug bounty program in the future. Researchers who have previously submitted valid reports may be invited to participate when this program launches.
7 Coordinated Disclosure
We believe in coordinated disclosure to protect our users:
- - We ask that you give us reasonable time (typically 90 days) to fix vulnerabilities before any public disclosure
- - We will coordinate with you on the timing of any public announcements
- - We will credit you in any public disclosure (unless you prefer to remain anonymous)
- - If you wish to publish your findings, we ask that you share your draft with us first
8 Contact Information
For security-related inquiries:
- Security Reports: security@createstate.ai
- General Inquiries: support@createstate.ai
- security.txt: /.well-known/security.txt
Related Policies: Privacy Policy | Terms of Service