https://chat.positive-intentions.com/
Security Assessment Summary
Overall Assessment
No exploitable vulnerabilities detected.
Executive Summary
Scope: Blackbox assessment of https://chat.positive-intentions.com/. The site is a static, client-only SPA (CloudFront/S3) for P2P chat leveraging PeerJS/WebRTC and a third-party analytics endpoint. No first-party authenticated APIs or server-side data storage were observed.
Key results:
- Authentication/Password reset: Not implemented by design; attempts to locate or trigger flows return the SPA shell. No enumeration, rate limiting, or reset-token issues applicable.
- Access control/IDOR/CSRF: Not applicable; no cookies or stateful HTTP endpoints on this origin.
- XSS: Reflected tests did not reflect payloads; no DOM-based exploit path demonstrated. CSP present but allows 'unsafe-eval'; recommend tightening for production.
- CORS: Static host replies with ACAO:* for OPTIONS on assets; third-party analytics preflight allows POST from any origin. No sensitive endpoints identified on this origin; no exploit confirmed.
- Security headers: HSTS, nosniff, and Referrer-Policy present. Missing COOP/CORP/Permissions-Policy and legacy X-Frame-Options; duplicate CSP (header + meta) and script-src 'unsafe-eval'. These are hardening gaps.
- Supply chain: Remote module federation loads code from GitHub Pages and a subdomain. No tampering observed; risk is inherent to remote code loading. Consider pinning, integrity controls, and consolidated trusted hosting.
- WebRTC/TURN: Uses public PeerJS TURN credentials; consider private TURN with ephemeral credentials.
- Soft-404: Unknown paths return 200 with SPA index; adjust to 404/405 to improve monitoring and reduce noise.
- Other checks: No cookies set; HTTP TRACE disabled (405); robots/sitemap endpoints return SPA index.
Recommendations (hardening):
- Tighten CSP (remove 'unsafe-eval' if possible; ensure a single authoritative policy; consider frame-ancestors). Add COOP/CORP/Permissions-Policy.
- Restrict CORS where unnecessary, especially on any future APIs.
- Prefer private TURN with time-limited credentials for production reliability/privacy.
- Serve remote modules from controlled origins with version pinning and integrity protections.
- Configure CDN/origin to return proper 404/405 for unknown routes, especially for POSTs.
Detailed Findings (9)
1. Reconnaissance / Endpoint Discovery
Analysis
Performed low-volume crawl and asset parsing. Site is a static SPA served via Amazon S3/CloudFront. Discovered primary assets and external dependencies (PeerJS, analytics, remote module federation remotes). No first-party REST/GraphQL endpoints on chat.positive-intentions.com; unknown paths resolve to SPA index (single-page-app fallback).
Vulnerable Code
Top endpoints/assets observed
- https://chat.positive-intentions.com/
- https://chat.positive-intentions.com/main.js
- https://chat.positive-intentions.com/manifest.json
- https://positive-intentions.github.io/cryptography/remoteEntry.js
- https://cryptography.positive-intentions.com/remoteEntry.js
- https://api.nlevelsoftware.com/analytics (third-party analytics API)Conclusion
No major vulnerabilities identified (recon only).
2. Security Headers / CSP
Analysis
Response headers show a reasonably strict baseline (HSTS, nosniff, Referrer-Policy). However, CSP allows 'unsafe-eval' and inline styles; duplicate/overlapping CSP appears in both HTTP header and meta tag. Legacy anti-framing (X-Frame-Options) and modern isolation headers (COOP/CORP/Permissions-Policy) are absent. This is a hardening gap rather than a directly exploitable flaw identified in testing.
Vulnerable Code
GET / HTTP/2
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
content-security-policy: default-src 'self'; ...; script-src 'self' 'unsafe-eval' ...; style-src 'self' 'unsafe-inline' ...; connect-src 'self' blob: wss://0.peerjs.com https://positive-intentions.metered.live https://api.nlevelsoftware.com/analytics https://*.clerk.dev ...
# Missing headers observed: X-Frame-Options, Cross-Origin-Opener-Policy, Cross-Origin-Resource-Policy, Permissions-PolicyConclusion
No exploitable vulnerability identified; security hardening recommended (tighten CSP, add COOP/CORP/Permissions-Policy, consider frame-ancestors).
3. CORS Posture
Analysis
Static host replies permissively to OPTIONS for some assets with ACAO: *. Third-party analytics endpoint explicitly permits cross-origin POST with Content-Type and X-Api-Key headers in preflight. No sensitive cookies or authenticated APIs on this origin were identified, so no exploit path was demonstrated.
Vulnerable Code
# Static asset preflight
OPTIONS https://chat.positive-intentions.com/main.js
access-control-allow-origin: *
access-control-expose-headers: *
# Third-party analytics API preflight
OPTIONS https://api.nlevelsoftware.com/analytics
access-control-allow-origin: *
access-control-allow-methods: OPTIONS,POST
access-control-allow-headers: Content-Type,X-Api-KeyConclusion
No exploitable vulnerability confirmed; CORS appears permissive but no sensitive endpoints identified.
4. Authentication & Password Reset
Analysis
No user/password authentication or registration exists on the target. Common auth/reset routes (e.g., /sign-in, /sign-up, /forgot-password) return the SPA shell. Bundle content states the app operates without registration and stores data locally. No verification/reset emails observed after attempts.
Vulnerable Code
GET /sign-in => 200 text/html (SPA index)
GET /login => 200 text/html (SPA index)
POST /forgot-password {email: ...} => 200 text/html (SPA index)
(Set-Cookie absent; no session cookies observed)Conclusion
No auth-related vulnerabilities (feature not present).
5. Access Control / IDOR / CSRF
Analysis
No server-side content or authenticated endpoints were discovered on chat.positive-intentions.com. With no cookies or state-changing HTTP APIs, classic IDOR and CSRF scenarios do not apply.
Vulnerable Code
GET /api/ => 200 text/html (SPA index)
GET /graphql => 200 text/html (SPA index)
(Set-Cookie: none; no CSRF tokens in play)Conclusion
No major vulnerabilities identified (not applicable to this static SPA).
6. XSS (Reflected/Stored/DOM)
Analysis
Reflected XSS probes on multiple paths/params returned only the SPA index, with no unencoded reflection. DOM sink search found usage primarily in framework/runtime (e.g., React/emotion dangerouslySetInnerHTML for styles, webpack new Function/eval in remote dev builds), but no user-controlled data flow into dangerous sinks was demonstrated.
Vulnerable Code
# Reflected XSS probes (truncated)
GET /?q=%3Cscript%3Ealert(1)%3C/script%3E => 200 SPA index (no reflection)
GET /login/test?xss=%3Cscript%3Ealert(1)%3C/script%3E => 200 SPA index
# Typical library/runtime sinks encountered (not app logic)
// emotion style injection
return createElement("style", { dangerouslySetInnerHTML: { __html: css } })
// webpack runtime pattern
return this || new Function('return this')();Conclusion
No XSS vulnerability found in tested surface; CSP still allows 'unsafe-eval' which should be avoided in production.
7. Client-side Supply Chain (Remote Module Federation)
Analysis
The app loads remote federated modules from external origins (GitHub Pages and cryptography subdomain). Remote bundles use webpack eval devtool. While common, this increases exposure to third-party compromise. No tampering observed during testing; risk is supply-chain in nature, not an immediate exploit.
Vulnerable Code
Remote modules observed at runtime:
- https://positive-intentions.github.io/cryptography/remoteEntry.js
- https://cryptography.positive-intentions.com/remoteEntry.jsConclusion
No immediate vulnerability confirmed; supply-chain exposure noted. Restrict/remediate as feasible (pin versions, integrity checks, controlled hosting).
8. WebRTC/TURN Configuration
Analysis
ICE servers include Google STUN and public PeerJS TURN servers with static, widely known demo credentials. This is operationally weak (reliability/abuse) and may route media via third-party relays. It is not an application secret leak. Consider private TURN with time-limited credentials for production.
Vulnerable Code
iceServers: [
{ urls: "stun:stun.l.google.com:19302" },
{ urls: [
"turn:eu-0.turn.peerjs.com:3478",
"turn:us-0.turn.peerjs.com:3478"
], username: "peerjs", credential: "peerjsp" }
]Conclusion
No vulnerability; hardening recommended (own TURN with ephemeral creds).
9. HTTP Responses for Nonexistent/Sensitive Paths (Soft-404)
Analysis
Requests to /.env, /.git/HEAD, /server-status, /.well-known/security.txt return 200 with SPA index (CloudFront SPA fallback) instead of 404. No sensitive data exposed, but this can confuse monitoring and scanners.
Vulnerable Code
HEAD /.env => 200 text/html (SPA index)
HEAD /.git/HEAD => 200 text/html (SPA index)
HEAD /server-status => 200 text/html (SPA index)
HEAD /.well-known/security.txt => 200 text/html (SPA index)Conclusion
No vulnerability; consider proper 404/405 responses for unknown routes.
BugBunny continuously probes your application with specialized AI agents, surfacing critical vulnerabilities before attackers do. Launch a guided audit in minutes and ship with confidence.