Pump Perps

The server reflects any Origin header value in the Access-Control-Allow-Origin response header while also setting Access-Control-Allow-Credentials: true. This means any website on the internet can make authenticated cross-origin requests to PumpPerps API endpoints using the victim's session cookies. An attacker could create a malicious page that silently reads the victim's account data (/api/auth/me, /api/stats), balance information, or potentially triggers state-changing actions. Verified by sending Origin: https://evil.com — server responded with access-control-allow-origin: https://evil.com and access-control-allow-credentials: true.

Several recommended security headers are absent from HTTP responses: (1) No Content-Security-Policy — increases XSS risk if any injection point is found. (2) No X-Frame-Options — the site can be embedded in iframes on other domains, enabling clickjacking attacks. (3) No X-Content-Type-Options — browsers may MIME-sniff responses. (4) No Referrer-Policy — full URLs may leak in referrer headers. (5) No Permissions-Policy — browser features (camera, microphone, geolocation) not explicitly restricted. (6) X-Powered-By: Express is present, disclosing the backend framework.

The /api/auth/check-email endpoint returns different responses based on whether an email address is registered ({exists: true} vs {exists: false}). This allows an attacker to enumerate valid user email addresses, which can be used for targeted phishing campaigns, credential stuffing, or social engineering against PumpPerps users.

Comprehensive analysis of the frontend JavaScript bundle (1.5MB) and all network activity found no evidence of malicious behavior. Specifically verified: no eval() or dynamic code execution, no external script loading, no hidden iframes, no drainer contract interactions, no setApprovalForAll patterns, no clipboard hijacking (all clipboard usage is standard copy-to-clipboard UX), no data exfiltration to third-party domains. All 124 network requests during testing went exclusively to pumpperps.com, fonts.googleapis.com, fonts.gstatic.com, and cdn.dexscreener.com (for token images). First-party analytics only (custom heartbeat system).

HTTP Strict Transport Security is correctly configured with a 2-year max-age and includeSubDomains directive, ensuring all connections are forced to HTTPS.

PumpPerps uses a custodial wallet model where users deposit USDC to an assigned Solana wallet address. Trading happens off-chain within the platform. No signTransaction, signAllTransactions, or signMessage calls were found in the frontend bundle. This architecture completely eliminates the most common attack vector in Solana DeFi — malicious transaction signing from browser wallets. Users' external wallets are never connected to the platform for transaction signing.

The platform offers TOTP-based two-factor authentication in the Settings page. Users can set up 2FA with an authenticator app. The setup flow uses standard QR code provisioning with manual secret backup. This is a strong security practice for a custodial trading platform.

The platform uses a custom first-party analytics system (heartbeat-based page tracking to /api/analytics/heartbeat) instead of third-party analytics services. No Google Analytics, no Meta Pixel, no tracking cookies from external domains. Session IDs are generated client-side using crypto.randomUUID() and stored in sessionStorage (cleared on tab close). This is a privacy-positive design choice.

The project has published comprehensive documentation including: a whitepaper and roadmap (PDF, 43KB), a docs section covering trading mechanics (long/short, pool tiers, fees, rug protection), Terms of Service, and Privacy Policy. The documentation explains the platform's mechanics transparently including fee structures, leverage limits, and rug protection mechanisms.