HarperFast / HarperFast/harper
Provide a built-in way to set security / cache response headers across all HTTP surfaces (esp. Fabric-hosted apps with no edge)
- Dominant language
- JavaScript
- Stars
- 89
- Forks
- 10
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 200
Description
## Problem
Harper has no built-in way to set security / cache response headers across its HTTP surfaces. Today an app can set headers only from **custom Resource** handlers via `context.responseHeaders.set(name, value)` — there is no mechanism to apply headers to the **auto-generated** REST/table/GraphQL endpoints, and no global/config-level control.
This is especially acute for **Harper-hosted (Fabric) deployments**, where there is no customer-controlled reverse proxy / CDN in front to add these headers — the common "set it at your edge" advice doesn't apply, so the headers simply can't be set at all for the auto-generated surfaces.
## What's missing
A configuration- (and/or platform-) level way to apply, across all HTTP surfaces:
- **Security headers**: `X-Content-Type-Options: nosniff`, `X-Frame-Options` / `Content-Security-Policy`, `Referrer-Policy`, `Strict-Transport-Security`, `Cross-Origin-*` (COOP/COEP/CORP), `Permissions-Policy`. (`nosniff` is the highest-value default.)
- **Cache-control policy**: e.g. `Cache-Control: no-store`/`private` on authenticated/authorized responses, and correct `Vary` — so responses aren't mis-cached by a shared cache.
Sensible secure defaults (at least `nosniff`) plus per-app/per-route overrides would cover both self-hosted and Fabric-hosted deployments.
## Related
These header gaps were surfaced by exploratory QA and are tracked as individual defects: CORS `Vary: Origin` (#1518), auth-response `Cache-Control`/`Vary` (#1565), and the security-header baseline. This issue is the umbrella capability that would let all of them be addressed centrally rather than per-endpoint — and is the only viable path for Fabric-hosted apps.
_— raised from Kris's exploratory-QA campaign (KrAIs)_
Contributor guide
Research direction
Start by tracing the existing custom Resource response-header path, including context.responseHeaders.set(name, value), and compare it with the auto-generated REST, table, and GraphQL surfaces. Define the configuration or platform entry point needed to cover all surfaces, then verify that secure defaults, cache policy, Vary handling, and per-app or per-route overrides meet the issue requirements.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript, node.js
- Domain
- api, backend, performance, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100