TrustLab: validate three source-grounded security audit leads #1588

A quick source-only security review of apps/trustlab at commit e61a0cbcfefbd2524e9fb3f5591040ce026b2fc6 produced three independently reviewed leads requiring validation. None is a confirmed vulnerability, and no severity is assigned. No application code, builds, tests, browser fixtures or deployment probes ran. No secret values were inspected or included.

1. Public page/post readers lack publication filtering

Pages and Posts enable drafts while using unconditional public read access. Public frontend/custom readers also omit a published-only predicate when calling the privileged Payload local API. Installed Payload source accepts a caller-selected draft option and queries the latest version without independently adding a publication restriction.

Source:

• Pages public access and drafts
• Posts public reads
• Local Payload wrapper
• Public page lookup and post listing
• Sitemap explicitly filters published pages

Needs validation: Actual responses for never-published drafts, newer autosaves of published records and explicitly unpublished records; intended draft confidentiality; deployed version and route restrictions. Access override and draft selection are distinct: ordinary reads must not be assumed to expose newer autosaves.

Bounded next step: In a separately authorized offline sandbox with dummy records, compare anonymous REST reads with draft mode enabled/disabled, ordinary frontend/custom listing reads and authenticated preview. Record only harmless marker disclosure or denial. If validated, enforce publication policy at collection reads and public local-query boundaries while preserving authorized preview.

2. Author-accessible post blocks reach raw HTML rendering

Posts accepts the full block registry, including ActionBanner.embedCode, under author-level creation access. Public rendering passes this content to AirtableEmbed, whose non-iframe fallback uses dangerouslySetInnerHTML. The application-defined production CSP includes unsafe-inline.

Source:

• Post creation and shared block schema
• Embed-code field
• Raw HTML fallback
• Source CSP

Needs validation: Actual author persistence and separate visitor-browser behavior; effective CSP/sanitization; whether authors are intentionally trusted to publish arbitrary active same-origin HTML. HTML insertion alone does not establish script execution.

Bounded next step: Establish the author-role trust policy first. In a separately authorized isolated sandbox, persist one schema-valid dummy author post and observe only a harmless local document marker in a separate dummy visitor browser. If authors should not have code-publishing authority, consider allowlisted iframe URLs, removal of raw HTML fallback, or stronger field authorization.

3. Revalidation credential comparison can fail open when configuration is absent

The revalidation handler compares a possibly absent request credential directly with REVALIDATE_SECRET, without first requiring a configured secret. If both values are absent, source control flow reaches res.revalidate for a supplied body path. A nonempty configured secret blocks that credential-free path.

Source: Revalidation handler.

Needs validation: Secret configuration presence, independent ingress controls, active dependency identity and actual handler/cache behavior. No deployed misconfiguration or cache mutation was observed.

Bounded next step: An owner checks only configuration presence and ingress restrictions, retaining no secret values and sending no audit traffic. A separately authorized isolated fixture can stub res.revalidate and compare missing versus nonempty dummy configuration. Reject missing/empty configured secrets before comparing credentials.

Follow-up checklist

• Validate publication policy across REST, public local readers and authorized preview.
• Establish author active-HTML trust policy and validate the embed boundary.
• Check revalidation configuration presence and add a fail-closed configuration guard.
• Record validation outcomes before assigning severity or treating these as confirmed vulnerabilities.

Coverage limits

This was a partial single-app quick pass using 10 sub-agent invocations, including independent review of all three leads. Deferred areas include upload content handling, cookie-authenticated mutation/CSRF behavior, account recovery and public-query resource amplification. Other apps, broad shared-package security, infrastructure/provider policy and dependency advisory review were outside scope. Artifact schema and coverage-ledger checks passed; those checks establish report consistency, not exploitability.