If you are interested in user facing changes you can probably skip this post and read the previous one here.
This post is mostly technical and focused on security related work on multiple PeakD + Peak Open repositories: XSS, CSP, SSRF, regex safety, and API abuse guardrails.
Also, huge thanks (and some rewards from this post) to 
Most of the security work this week happened here, mostly around browser-side protections and safer content loading.
Nice side effect of this round: peakd.com now shows an A+ on SecurityHeaders (up from the A score we had since day 1): https://securityheaders.com/?q=peakd.com&followRedirects=on
What changed:
- Tightened what external images the browser is allowed to load to enforce strict privacy when loading images from un-trusted sources
- Reduced overly broad defaults and moved to a stricter allowlist approach
- Improved script-loading protection so each page request gets a fresh safety token
- Applied stricter rules to API endpoints and static resources
- Tuned PWA and service worker behavior so it stays aligned with the same security posture
Net effect: stricter defaults, cleaner policy behavior, and stronger protection against content injection issues.
Repo: https://gitlab.com/peakd/peak-image-proxy
This one got a solid hardening pass focused on network exposure and input validation.
What changed:
- Added stronger safeguards to block risky internal-network fetch attempts
- Tightened how incoming image URLs are parsed and validated
- Switched cross-origin access to a clear allowlist model
- Reduced operational details exposed by health/status responses
- Hardened accepted file-type handling for image processing
- Upgraded hashing used in cache keys to a stronger standard
This is a meaningful improvement for both SSRF risk and general attack surface minimization.
Repo: https://gitlab.com/peakd/peak-notification-system
Here the focus was on regex safety and API boundary limits.
What changed:
- Added safety checks for regex-based rules to avoid abusive patterns
- Added size limits to reduce risk from expensive pattern matching
- Improved handling so repeated checks are cheaper and more predictable
- Enforced stricter pagination limits to prevent heavy or abusive API queries
The regex hardening is especially important because account-level config can otherwise become a performance/security footgun very quickly.
Repo: https://gitlab.com/peakd/sting-message-frontend
Main fix here was tightening link handling to reduce XSS injection risk.
What changed:
- Improved link sanitization in rendered messages
- Limited links to safe protocols and safe navigation targets
- Invalid or suspicious links are now neutralized instead of opened
- Improved external-link handling to reduce tab hijacking risk
This closes the classic "user-controlled link value" hole where bad schemes can sneak into rendered anchors.
Security hardening is always ongoing work.
This week was heavier than usual because
AI tools are now opening up easier and cheaper ways to run security audits across large codebases, and I’m glad we have such a strong Hive community helping build and improve these apps around the clock.
We’ll keep shipping this kind of work in parallel with features, because the best time to harden systems is before we get surprised.