-
Notifications
You must be signed in to change notification settings - Fork 0
Safety and Security
Proton Pulse handles Steam identities and user-submitted data. This page documents what we do to keep things secure, and what automated scanning runs continuously on the project.
- Your Steam display name and avatar (public Steam profile info)
- Hardware specs (CPU, GPU, RAM, OS) when you submit a report
- Compatibility ratings and notes you write
- Your Steam library (list of owned app IDs, used for the My Library filter)
We do not store your email, IP address, real name, or any payment info. Your Steam password never touches our systems. Authentication uses Steam OpenID, which means you log in directly with Valve and we receive a verified Steam ID back.
Sign-in uses Steam OpenID 2.0 via a Supabase Edge Function. The flow:
- You click Sign In, which redirects to Steam's login page (on
steamcommunity.com) - Steam verifies your credentials and redirects back to our callback
- Our callback verifies the OpenID assertion with Valve's servers
- A session token is issued and stored in your browser
At no point does Proton Pulse see or store your Steam password. The session token expires and must be refreshed by re-authenticating.
These run continuously on every push and PR:
| Scanner | What it checks | Frequency |
|---|---|---|
| CodeQL (GitHub Advanced Security) | Static analysis for XSS, injection, auth bypass patterns in JS/TS | Every push to main/staging, weekly scheduled |
| Dependabot | Known vulnerabilities in npm and pip dependencies | Daily |
| npm audit | High/critical CVEs in the dependency tree | Every PR, push to main/staging |
| Attachment scanner | Malware in issue/PR uploads via VirusTotal hash lookup + PE header sniffing | Every issue/comment created |
See Security-Guardrails for details on the attachment scanner.
Every database table uses Supabase RLS policies. Users can only read/write their own data. Specifically:
- You can only delete your own reports (verified by matching your user ID)
- Your Steam library, system profiles, and preferences are private to your account
- Admin actions require explicit permission grants (stored in an admins table with granular roles)
- Public data (compatibility reports, ratings) is read-only to everyone, write-only by the author
The site ships a Content Security Policy that restricts script sources, prevents inline script injection, and limits which domains can load resources. This mitigates XSS even if a bug allows HTML injection.
| Layer | Technology | Security posture |
|---|---|---|
| Hosting | GitHub Pages (static files only) | No server-side execution. No database access from the host. Immune to server-side injection. HTTPS enforced by GitHub. |
| Frontend | Vanilla JavaScript (ES modules, no framework) | No build step means no supply chain through bundlers. Code is auditable as-shipped. |
| Auth + database | Supabase (PostgreSQL + Edge Functions on Deno) | Row-Level Security on every table. JWTs with short expiry. Service role key never exposed client-side. |
| CDN dependencies | Supabase JS SDK, markdown-it, Chart.js (all from jsdelivr) | Pinned to specific major versions. Subresource Integrity (SRI) planned. |
| Data pipeline | Python (runs in GitHub Actions CI only) | No user input reaches subprocess calls. All API responses are treated as untrusted strings. |
| Edge Functions | Deno (TypeScript, runs on Supabase infrastructure) | Per-function rate limiting. Input validation on all endpoints. CORS restricted where possible. |
GitHub Pages specific considerations:
- No server-side code execution. The site is purely static HTML/JS/CSS.
- No cookies set by the site (auth tokens live in sessionStorage/localStorage).
- GitHub enforces HTTPS with their own certificate. No mixed content.
- No custom server headers (CSP is delivered via meta tag since GH Pages does not support custom HTTP headers).
- The gh-pages branch is deployed via GitHub Actions workflow with branch protection. Manual pushes to gh-pages are not possible.
Standards and references:
- OWASP Top 10 (2021) - XSS mitigated via DOM-based escaping + CSP (A03:2021), injection prevented by parameterized queries (A03:2021), auth bypass prevented by RLS + JWT verification (A01:2021)
- OWASP ASVS v4.0 Level 1 - session management, input validation, output encoding, access control
- CWE-352 (CSRF) - not applicable (bearer token auth, no cookie-based sessions)
- CWE-601 (Open Redirect) - validated against known origins in both client and server callback
- GitHub Pages security model - static hosting with enforced HTTPS, no server-side execution
All public edge functions enforce per-IP rate limits (30 requests per minute). The plugin-link endpoint uses a stricter limit (10 per minute) since it generates link codes. Rate limiting is per-isolate (Deno edge runtime) which stops single-source burst attacks. Distributed attacks are mitigated by Supabase's infrastructure-level protections.
Manual security audits are conducted periodically. Each audit gets its own wiki page with findings, status, and remediation timeline:
- Pentest-2026-07-14 - Initial comprehensive audit (auth flow, RLS, XSS, edge functions, data pipeline)
If you find a security issue, please report it privately via GitHub's Security Advisories tab on the repository, or email mdeguzis@gmail.com directly. Do not open a public issue for security vulnerabilities.
Parts of this project use AI tools for code generation and review. All AI-generated code goes through the same PR review, automated scanning, and manual testing as human-written code. The security scanners listed above run on every change regardless of who or what wrote it.