fix(security): resolve audit findings — logging, endpoints, contact details #3
Reference in New Issue
Block a user
Delete Branch "fix/security-audit"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Addresses the RE:Quest code-audit findings for the web app. 10 files, all
low-risk: no logic changes, no new dependencies, no API changes.
Security
pages ran
console.log('Updating … password:', data), writing the submittedform — including current and new password — to the console in cleartext.
Password changing itself is unaffected:
PasswordSecurityFormposts to/auth/change-passworddirectly, the removed handler was only a logging stub."**"with an explicit allowlist(Contabo, AWS, DigitalOcean Spaces).
hostname: "**"allowed the Next imagehandler to fetch from any host — an SSRF/abuse surface.
Vendor decoupling
layout.tsxhardcodedhttps://analytics.superlabs.co/script.jswith a fixeddata-website-id, so visitor data flowed to a vendor-owned instance. Now readsNEXT_PUBLIC_UMAMI_URL/NEXT_PUBLIC_UMAMI_WEBSITE_IDand renders nothing whenunset — production currently sets neither, so no analytics script is emitted.
Correctness
Socket URL fallback fixed to
http://localhost:3001/api/v1(washttp://localhost:4000). The socket base URL is derived by stripping/api/v1off the API URL; the old fallback had no such suffix, so the strip was a no-op and
:4000passed through. Giving the fallback the same shape as the real env varmeans one code path handles both. Confirming the audit's §7 question:
:4000wasa stale value, not a separate service — the only remaining
4000in the repo isan unrelated
setTimeout.Note this fallback only ever applied in local dev, since production sets
NEXT_PUBLIC_API_URL. The production-side websocket fix is in the backend PR(
CORS_ORIGINSbeing read before.envloaded).Contact details
Replaced placeholder and personal contact emails with
support@re-quest.comacross contact, FAQ, privacy policy, terms of service and the subscription form.
These were user-facing on the legal pages and included personal Gmail accounts
(
request.sha@gmail.com,officialteam.request@gmail.com), a placeholder(
123support@gmail.com), andsupport@requesn.com— a misspelled domain, sothat mailto link was broken.
⚠️
support@re-quest.comneeds to be a live, monitored mailbox before this ships— it is now the published support address on the legal pages.
Verification
next buildandtsc --noEmitclean.Not addressed (acknowledged in the audit, needs a decision)
Auth tokens are still written to
localStorage(login,verify-2fa,services/api.ts), which is XSS-exfiltratable. The audit asked only foracknowledgement here. Moving to httpOnly cookies is a behaviour change affecting
the whole auth flow and should be its own PR, not bundled with a go-live fix.