Contractor Access to a Header-Authenticated Wiki
Northwind has 420 employees and 60 contractors. Its internal wiki runs on nginx behind an old reverse proxy that trusts an X-Auth-User header. The company is replacing the VPN with Cloudflare Access and has enrolled 70% of managed laptops in WARP; contractors use unmanaged laptops and are not required to install WARP. The wiki must be readable by all employees on managed, encrypted devices, and by eight auditors from one agency for a 90-day window. A vendor server must POST to /api/nightly using a service token. During pilot, an engineer added an Access Bypass policy for /api to make the vendor work. Now contractors can open the wiki from personal laptops, and the vendor still gets 403s on some nights. The security team wants a design that is least-privilege, auditable, and does not break the nightly job.
1. Design the Access policy set for the wiki and the vendor API. Explain how each rule is scoped and why the Bypass policy is unsafe.
Read the worked answer
Put an Access application on the wiki hostname, not a Bypass path. Use explicit Allow rules: (1) employees group plus device posture such as disk encryption, OS version, and WARP enrollment; (2) auditors group plus MFA and a 90-day Access group; (3) a Service Auth rule for the vendor token, scoped to /api/nightly. Remove the Bypass rule. Bypass skips identity and posture for every request matching /api, and because paths are evaluated within the same application it can expose more than intended. Service tokens belong in a Service Auth policy using CF-Access-Client-Id and CF-Access-Client-Secret headers, not in Bypass. Contractors cannot satisfy device posture on unmanaged laptops, so do not pretend they do. If they must use unmanaged devices, require MFA and isolate the session, or issue managed devices. For read-only, enforce authorization in nginx or a read-only mirror on a separate hostname; Access is an authentication gate, not an application RBAC engine.
2. The vendor still receives intermittent 403s. What are the most likely causes, and what evidence would you collect?
Read the worked answer
Intermittent 403s usually mean the service token is not presented on every request, the secret rotated, the request path does not match the Service Auth rule, or another policy blocks first. Collect the exact timestamp and URL, response headers including CF-Ray and any Access error code, whether CF-Access-Client-Id and CF-Access-Client-Secret are present, token age, and Gateway HTTP logs if the traffic passes WARP. Check whether the vendor follows redirects and drops custom headers on the redirect, or calls a different hostname or path. Reproduce with curl using the same headers. If the 403 is an Access deny, the audit log shows the applied policy; if it is nginx, the request reached the app without the expected header. Fix by pinning the token to the exact host and path and documenting header persistence across redirects.
3. Auditors need read-only access, but Access does not enforce read-only at the application layer. What compensating controls would you recommend?
Read the worked answer
Use application-layer authorization first: put the wiki behind an app that supports read-only roles, or create a separate read-only view. If that is impossible, add an nginx rule that permits only GET and HEAD for the auditor group and logs POST, PUT, and DELETE attempts. Require MFA and short session durations, restrict auditors by country or IP if practical, and enable Access audit logs with review. For unmanaged devices, use browser isolation to reduce downloads and copy-paste risk, and add a Gateway DLP policy for the contractor group to block posting sensitive data. Do not rely on hiding edit buttons. Test the read-only rule with a canary auditor before the 90-day window and keep a rollback path.