Security Policy

1. Our Commitment to Security

Security is built into the current SuperHubber codebase through server-side validation, protected sessions, prepared database access, and restrictive HTTP headers. This page describes the controls that are implemented today in the repository, rather than aspirational or planned features.

2. Account Security

2.1 Password Protection

• Passwords are not stored in plain text. New passwords are hashed with bcrypt using PHP's password_hash() at cost 12.
• Passwords must be between 8 and 72 characters to align with bcrypt's input limits.
• On successful login, password hashes are automatically rehashed if the configured bcrypt cost changes in the future.

2.2 Session Management

• Authenticated sessions use cookies configured with the Secure, HttpOnly, and SameSite=Strict flags.
• Sessions expire after a period of inactivity based on the configured server-side session lifetime.
• Session IDs are regenerated on login, and the active session is bound to a server-side fingerprint derived from the browser user agent.

2.3 Remember-Me Tokens

• Optional persistent login uses a selector and validator token pair instead of storing a reusable password equivalent in the browser.
• The validator value is hashed with SHA-256 before it is stored in the database.
• Remember-me tokens are rotated after successful restoration, and a mismatch causes all active remember-me tokens for that account to be revoked.

2.4 Login Rate Limiting

• Failed login attempts are recorded against both the submitted email address and the originating IP address.
• When the configured threshold is exceeded within the lockout window, further login attempts are blocked temporarily.

3. Data Encryption

• In transit: The application sends an HSTS header and marks session cookies as secure. TLS termination and HTTPS enforcement are handled by the production hosting and edge setup.
• At rest: Passwords are stored as bcrypt hashes. This page does not claim full-database or filesystem encryption at rest because that is not demonstrated in the application codebase.

4. Infrastructure Security

• Sensitive application directories such as includes/ and setup/ are blocked from direct web access with Apache Require all denied rules.
• Directory listing is disabled at the web root.
• The setup directory is denied at the web server level, and the installer also writes a lock file after a successful setup so it cannot be rerun accidentally without deliberate manual intervention.

5. Application Security

• State-changing forms such as login, registration, logout, forum posting, and voting are protected with per-session CSRF tokens that are verified server-side and rotated after successful submission.
• User-supplied values rendered into HTML are escaped with htmlspecialchars() using UTF-8 and quote escaping.
• Redirect targets are validated so the application only redirects to same-origin relative paths or exact same-origin absolute URLs.
• Database queries use PDO prepared statements with emulated prepares disabled, reducing SQL injection risk from dynamic input.
• Server-side access checks are enforced on protected pages through authentication and minimum-role guards before sensitive content is rendered.
• Apache sends Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, HSTS, and clickjacking protection headers. The current CSP is compatibility-focused and still allows inline scripts and styles where required by the existing frontend.

6. Third-Party Integrations

The production site integrates third-party services such as CoinGecko market data and Cloudflare-delivered analytics/runtime services. This page only claims the restrictions visible in application code and response headers, not contractual or vendor-governance controls that are outside the repository.

7. Incident Response

If you believe you have identified a security issue, please report it directly so it can be investigated and prioritised. This page does not promise specific notification timelines or post-incident publication steps that are not formalised in code or policy elsewhere in the repository.

8. Responsible Disclosure

We welcome responsible vulnerability reports from members and researchers.

• Email: security@superhubber.com
• Include: a clear description of the vulnerability, steps to reproduce it, the potential impact, and any supporting evidence (screenshots, HTTP logs).
• We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to investigate and remediate it (coordinated disclosure).

In Scope

• Public pages and authenticated workflows on superhubber.com that are served by this application.
• Authentication, session handling, forum interactions, and payment callback handling implemented in this repository.

Out of Scope

• Denial-of-service or resource exhaustion attacks.
• Physical attacks against our infrastructure.
• Social engineering of our staff.
• Vulnerabilities in third-party software or services not under our control.
• Any testing that involves accessing or modifying data belonging to other users.

9. Tips for Members

You can significantly reduce your risk by following these practices:

• Use a strong, unique password for your SuperHubber account — never reuse passwords from other sites.
• Never share your account credentials with anyone, including SuperHubber staff (we will never ask for your password).
• Be cautious of phishing emails or DMs impersonating SuperHubber. Always check the sender's email domain.
• Never share your cryptocurrency wallet seed phrases or private keys with anyone, under any circumstances.
• Keep your device's operating system and browser updated.

10. Contact

Security reports: security@superhubber.com
General enquiries: hello@superhubber.com

11. Platform Security Implementation

The following technical controls are currently implemented in the SuperHubber codebase and web-server configuration.

11.1 Cross-Site Request Forgery (CSRF) Protection

State-changing forms use a cryptographically random per-session CSRF token. Tokens are verified server-side using constant-time comparison and rotated after successful submission.

11.2 Output Escaping & XSS Prevention

All user-supplied data rendered in HTML pages is passed through a strict output-escaping layer using PHP's htmlspecialchars() with ENT_QUOTES | ENT_HTML5 and UTF-8 encoding, preventing reflected and stored cross-site scripting attacks.

11.3 Open Redirect Protection

All server-side redirects are validated against a strict allowlist. Only same-origin relative paths or absolute URLs matching the application's registered domain and scheme are permitted. Protocol-relative URLs (e.g. //evil.com) and external hosts are explicitly blocked.

11.4 Secure Session Management

Sessions use HttpOnly, Secure, and SameSite=Strict cookie flags. Each session is bound to a server-side fingerprint derived from the client's user agent string. Sessions expire after a configurable idle timeout and the session ID is regenerated on every login to prevent session fixation.

11.5 Remember-Me Token Security

Persistent login tokens use a selector/validator model. The selector is stored publicly in the cookie; the validator is hashed with SHA-256 before being stored in the database. On each use the token is rotated (old token revoked, new token issued). If a token mismatch is detected — indicating possible theft — all active tokens for the affected account are immediately revoked.

11.6 Login Brute-Force Protection

Failed login attempts are recorded against both the submitted email address and the originating IP address. Accounts and IP addresses that exceed the configured threshold are locked out for a defined window. Rate-limiting counters use server-side database records and are not bypassable by cookie manipulation.

11.7 Password Hashing

All passwords are hashed using bcrypt at work factor 12 via PHP's password_hash(). On each successful login the stored hash is checked against the current parameters and automatically rehashed if the work factor has been increased, ensuring the password store stays up to date without requiring user action.

11.8 Role & Plan-Based Access Control

Every authenticated page enforces access checks at the server level. Pages requiring a login call auth_require() before any output is produced. Pages requiring a minimum privilege level call auth_require_level(), which checks the user's numeric role level against the required threshold. Unauthenticated or under-privileged requests are redirected before any sensitive data is rendered.

11.9 Payment Webhook Security

The payment callback endpoint operates without the normal user authentication bootstrap, accepts POST requests only, validates an HMAC signature against the configured webhook secret, and applies recognised upgrades inside a database transaction. The broader payment flow still depends on the connected gateway configuration and business rules in production.

11.10 SQL Injection Prevention

The platform exclusively uses PDO with real prepared statements (ATTR_EMULATE_PREPARES = false). No string interpolation is used to construct SQL queries. Named parameters are unique per query to comply with the strict requirements of non-emulated prepared statements.

11.11 HTTP Security Headers

The following response headers are applied globally via Apache configuration:

• Strict-Transport-Security (HSTS) — instructs supporting browsers to prefer HTTPS.
• Content-Security-Policy (CSP) — restricts resource loading to trusted origins.
• X-Frame-Options: SAMEORIGIN — limits iframe embedding to the same origin.
• X-Content-Type-Options: nosniff — prevents MIME-type sniffing attacks.
• Referrer-Policy — limits referrer data sent to third parties.
• Permissions-Policy — disables unnecessary browser features.

11.12 Directory & File Access Controls

Sensitive directories — including includes/ and setup/ — are blocked from direct web access via Apache Require all denied directives. Directory listing is disabled at the application root. After a successful setup, the installer also writes a lock file so the setup flow is not rerun unintentionally.