Security & compliance
Security & OWASP alignment
StreamWizard follows established security standards. This page summarizes which OWASP guidelines we align with and which technical controls we implement.
1. Standards we follow
- OWASP Top 10 (2025) – the ten most critical risks for web applications.
- OWASP ASVS v4.0.3 – requirements catalogue for secure web applications (Level 1 as a baseline, Level 2 for security-critical paths such as login, licensing, payments).
- OWASP Cheat Sheet Series – concrete guidance on sessions, CSP, password/token storage, logging, etc.
- OWASP Secure Headers Project – reference for security-related HTTP headers.
We treat these standards as an ongoing process: controls are reviewed regularly and adapted to new recommendations.
2. OWASP Top 10 (2025) – how we address the risks
| Risk | Controls at StreamWizard |
|---|---|
| A01 – Broken Access Control | Centralized session checks and a fail-closed access guard, role-based access (owner/delegate/admin), license and API-key validation, signed one-time tokens for downloads, tenant delegation with revocation, non-delegable admin entitlement for Streamstats. Server-side image fetches with creator-influenced URLs pass through a central SSRF guard (https-only, blocking private/loopback/link-local/CGNAT targets via DNS resolution, IP pinning against DNS rebinding, redirect revalidation). |
| A02 – Security Misconfiguration | Strict Transport Security, Content Security Policy with nonces, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, X-XSS-Protection: 0 (OWASP-compliant), hardened .htaccess rules for API, assets, and no-store on sensitive API endpoints. |
| A03 – Software Supply Chain Failures | Vendored third-party libraries with Subresource Integrity (SRI) and a versioned vendor manifest with drift checks; continuous CVE scanning (OWASP dependency-check) and SBOM generation (CycloneDX) of the Java modules in CI, build fails at CVSS ≥ 7; pinned dependency versions; full third-party list published on the site. |
| A04 – Cryptographic Failures | Sensitive identifiers and centrally held feature tokens are stored using the enc/hash model: SHA-256/HMAC-SHA-256 for lookups, AES-GCM for reversible values. TLS 1.2+ enforced, HSTS active, secret keys are rotatable and documented. |
| A05 – Injection | Prepared statements (PDO) only for SQL, context-aware escaping (htmlspecialchars with ENT_QUOTES), strict input validation at system boundaries. |
| A06 – Insecure Design | Data minimization (e.g. only control metadata in backup queues and no permanent storage of Streamstats chat text), single-instance lock for license enforcement, layered permission models for delegates. |
| A07 – Authentication Failures | OAuth via Discord/Twitch/Kick, secure session configuration (HttpOnly, Secure, SameSite), session regeneration after login for all logged-in users, session token entropy per OWASP recommendation, brute-force protection via rate limiting. |
| A08 – Software or Data Integrity Failures | Signed release artifacts (YubiKey/PKCS#11), fail-closed integrity verification before every installation: the OBS plugin verifies its update manifest including the SHA-256 checksum against a compiled-in public key, the Java modules verify their signature against a pinned fingerprint, SHA-256 integrity header (Repr-Digest) on static downloads, signed one-time download links, verified Stripe webhook signatures. |
| A09 – Security Logging & Alerting Failures | Security events are logged (logins, API calls, download events, SSRF blocks). IP addresses are anonymized to prefixes (IPv4 /24, IPv6 /64); sensitive values are not written to logs. Critical patterns (clustered auth failures, invalid OAuth states, CSP/SSRF spikes) auto-escalate via thresholds and alert – deduplicated and fail-open – through a Discord webhook and/or email. |
| A10 – Mishandling of Exceptional Conditions | Security-critical paths (auth, license, crypto, signature verification, access control) are fail-closed – on error access is denied, not granted. No silent swallowing of exceptions (logging required), no stack-trace leaks to users (display_errors disabled, generic error pages). Documented exception-handling policy. |
3. Additional technical controls
- Content Security Policy with a per-request nonce for scripts and styles.
- Rate limiting on API and login endpoints against brute force and scraping.
- Subresource Integrity (SRI) for first-party and vendored assets.
- Cookie consent layer with separated Necessary / Analytics / Marketing categories.
- Documented key rotation for API, crypto, and webhook secrets.
- Separation of license data and bot control data – delegates do not get access to payment or license information.
- Central SSRF guard for server-side image fetches: https-only, blocking private/loopback/link-local/CGNAT targets via DNS resolution, IP pinning against DNS rebinding.
- Active security alerting: clustered critical events auto-escalate (threshold + dedup) via Discord webhook and/or email.
- Continuous supply-chain scanning: CVE checks (OWASP dependency-check) and SBOM (CycloneDX) of the Java modules in CI, runtime signature verification of update artifacts before installation.
4. Responsible disclosure
Please do not disclose vulnerabilities publicly. Report them confidentially:
- Email: support@streamwizard.de
- Subject:
Security Report - StreamWizard
We acknowledge reports within 72 hours and usually provide an initial triage within 7 days. Coordinated disclosure after a fix is available is explicitly welcome.
5. Note on compliance
"OWASP-aligned" here means: StreamWizard follows the OWASP projects listed above and actively implements their recommendations. This does not constitute an official certification by OWASP or any external auditor. OWASP is a registered trademark of the OWASP Foundation.