Application Security Transparency Report

· PayCal Security

Report Metadata

  • Date: 2026-03-31
  • Scope: PayCal web application — redirect handling, header trust, billing mutation safety
  • Reference: Internal security sweep 2026-03-31

Trigger

This review was prompted by the Axios npm supply-chain incident, which generated significant discussion about realistic web-application attack surfaces. Reporting on that incident appeared across BleepingComputer, Hacker News, and The Register. Rather than reacting with theoretical hardening, we performed a targeted review of the paths most relevant to our architecture.

Three Key Outcomes

  • Redirect handling — open redirect vector fixed; strict same-origin enforcement applied.
  • Header trust — host poisoning vector closed; forwarded headers accepted only from known infrastructure.
  • API protection — billing mutation endpoints now require CSRF validation at the controller boundary.

What We Fixed

1. Redirect Safety

PayCal uses redirect parameters in several authentication and navigation flows. Prior to this sweep, redirect targets were validated against a permissive allowlist that could be bypassed with protocol-relative URLs. We tightened this to:

  • Strict host validation — only the application's own origin is accepted.
  • Same-origin only — protocol-relative and scheme-less paths are rejected.
  • Default fallback to / — malformed or disallowed redirect values result in a safe default destination.

This eliminates the primary open-redirect attack path used to facilitate phishing campaigns against users who trust a link containing a recognisable domain.

2. Header Trust Boundaries

Several application features use forwarded IP and host headers for rate-limiting, audit logging, and geo-aware responses. These headers are trivially forgeable when accepted unconditionally.

  • Trusted proxy gating — headers accepted only when the request arrives via known infrastructure addresses.
  • Forwarded headers from known infrastructure only — all other sources are treated as untrusted.

This prevents host-poisoning attacks where an attacker injects a malicious Host or X-Forwarded-Host header to influence link generation, cache poisoning, or password-reset URL construction.

3. CSRF Protection on Billing Mutations

Billing mutation endpoints — charge initiation, subscription modification, payment method update — were accessible to any authenticated request, including cross-origin ones constructed via a victim's browser session.

  • CSRF validation is now enforced at the billing controller boundary.
  • Mutations require a synchronised token that an attacker cannot read from a cross-origin context.

Additional Review

Command execution surfaces (shell invocations, process spawns, system calls) were reviewed as part of this sweep. No active exposure was identified.

Verification

  • PHP linting — all modified files pass php -l.
  • Static diagnostics — PHPStan analysis clean at configured strictness level.
  • Manual inspection — affected code paths reviewed end-to-end.

Security Principles Applied

  • Default deny — reject anything not explicitly permitted.
  • Explicit trust boundaries — infrastructure sources declared, not inferred.
  • Validation at external inputs — untrusted data sanitised before any internal use.
  • Centralised controls — security logic in one authoritative location per concern.

What This Means for Users

  • Reduced phishing risk — links constructed using the PayCal domain cannot be weaponised to redirect users to attacker-controlled pages.
  • Stronger billing guarantees — billing actions require explicit user intent from the same origin; no cross-origin request can trigger a charge.

Ongoing Work

  • Integration tests targeting redirect safety, CSRF enforcement, and proxy header gating.
  • Periodic scans of new endpoints as features are added.

Files Updated

  • html/lang/index.php
  • html/src/Controllers/BillingController.php
  • html/js/core/billing.js

Our goal in this type of review is straightforward: eliminating realistic exploitation paths, not theoretical edge cases. The three outcomes above address real-world attack techniques that are actively exploited against similar applications.