Security Policy

1. Our Commitment to Security

At Beacon, security is fundamental to the trust our customers place in us. As a platform that organizations rely on to communicate their own service availability, we hold ourselves to a high standard of security practice. This document describes the technical and organizational measures we employ to protect the Service and your data.

2. Infrastructure Security

• TLS everywhere: all connections to the Service are encrypted using TLS. Unencrypted HTTP requests are automatically redirected to HTTPS. We enforce modern TLS versions and strong cipher suites.
• Encrypted database connections: connections between the application and database servers are encrypted in transit. Database access is restricted to application servers only.
• Secrets management: all sensitive configuration values, including API keys, database credentials, and encryption keys, are stored as environment variables or in encrypted secrets stores. Secrets are never committed to source control.
• Network isolation: production infrastructure is deployed with network-level isolation. Database and internal services are not directly accessible from the public internet.
• Regular backups: automated, encrypted backups of all databases are performed on a regular schedule. Backup integrity is verified and restoration procedures are tested periodically.

3. Application Security

• CSRF protection: all state-changing requests are protected against cross-site request forgery using signed tokens verified on every request.
• XSS prevention: all user-supplied content is escaped by default in templates. Content Security Policy headers provide an additional layer of defense against cross-site scripting attacks.
• SQL injection prevention: the application uses a parameterized query builder and ORM (Laravel Eloquent) for all database interactions. Raw queries are avoided; where necessary, they use parameter binding exclusively.
• Rate limiting: API endpoints, authentication routes, and public-facing endpoints are protected by rate limiting to prevent brute-force attacks and abuse. Rate limits are applied per-IP and per-workspace.
• Input validation: all user input is validated server-side before processing. File uploads, if applicable, are restricted by type and size.
• Dependency management: application dependencies are regularly reviewed and updated to address known vulnerabilities.

4. Authentication

• Password hashing: all passwords are hashed using bcrypt with a sufficient work factor. Plaintext passwords are never stored or logged.
• OAuth integration: the Service supports single sign-on via Google and GitHub using industry-standard OAuth 2.0 flows. OAuth client secrets are stored securely and rotated as needed.
• Email verification: new accounts are required to verify their email address before gaining full access to the Service.
• Session management: sessions are managed using secure, signed cookies with appropriate expiration. Sessions are invalidated on logout and on password change.

5. API Security

• Token-based authentication: API access is authenticated using bearer tokens scoped to individual workspaces. Tokens can be revoked at any time through the workspace settings.
• Webhook signatures: outbound webhooks are signed using HMAC-SHA256 with a per-workspace secret key. Recipients should verify the signature before processing any webhook payload.
• Rate limiting: API rate limits are enforced on a per-workspace and per-IP basis. Rate limit status is communicated through standard HTTP response headers.
• Token storage: API tokens are stored as irreversible hashes. The plaintext token is shown only once at the time of creation and cannot be retrieved afterward.

6. Data Handling

• Encryption at rest: sensitive data fields, including API tokens and webhook secrets, are encrypted at the application level before storage.
• Token hashing: API tokens and other bearer credentials are stored as one-way hashes. Even in the event of a database compromise, these values cannot be reversed to their original form.
• Cryptographic randomness: webhook secrets, API tokens, and other security-critical values are generated using cryptographically secure random number generators.
• Data isolation: workspace data is logically isolated. Access controls ensure that users can only access data within workspaces to which they have been granted membership.

7. Monitoring and Logging

• Application logging: the Service maintains detailed application logs for debugging, audit, and security analysis. Logs do not contain plaintext passwords, API tokens, or other sensitive credentials.
• Error tracking: application errors are captured and triaged to ensure timely resolution of issues that may affect security or reliability.
• Uptime monitoring: the infrastructure and application are continuously monitored for availability and performance degradation.
• Audit trails: administrative actions within workspaces are recorded in audit logs to support accountability and forensic investigation.

8. Incident Response

We maintain an incident response process for security events. Upon becoming aware of a potential security incident:

• The incident is investigated and triaged within 24 hours of discovery
• Containment measures are implemented to limit the scope and impact of the incident
• Affected customers are notified promptly with relevant details about the incident and any actions they should take
• A root cause analysis is conducted and remediation steps are implemented to prevent recurrence
• Applicable regulatory authorities are notified as required by law

9. Responsible Disclosure

We welcome and appreciate reports from security researchers who discover vulnerabilities in the Service. If you believe you have found a security vulnerability, please report it to us at security@beaconstatus.com.

When reporting a vulnerability, please include:

• A description of the vulnerability and its potential impact
• Steps to reproduce the issue
• Any supporting evidence such as screenshots or proof-of-concept code

We commit to the following in response to good-faith security research:

• We will not pursue legal action against researchers who report vulnerabilities in accordance with this policy
• We will acknowledge receipt of your report within 48 hours
• We will work with you to understand and validate the issue
• We will keep you informed of our progress toward remediation

We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to address it, and that you do not access, modify, or delete data belonging to other users during your research.

10. Subprocessors

The following third-party service providers process data on our behalf as part of operating the Service:

• Stripe — payment processing and subscription billing
• Email service provider — delivery of transactional notifications, including incident alerts, team invitations, and billing communications
• Hosting provider — application hosting, database hosting, and infrastructure services

Each subprocessor is selected for its security practices and is bound by contractual obligations to protect your data. We regularly review our subprocessors to ensure they continue to meet our security standards.

11. Contact

For security-related inquiries, vulnerability reports, or questions about this policy, please contact us:

security@beaconstatus.com