fix: site write access must not implicitly grant CONFIG write#306
Merged
Conversation
/site/CONFIG was reachable via any /site/** or /site/+** write rule, so anyone with write access to content could also write the config. Config write now requires an explicit rule targeting the CONFIG keyword itself (site or org level); wildcard/recursive site rules still imply CONFIG read. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
bosschaert
approved these changes
Jul 21, 2026
tripodsan
approved these changes
Jul 21, 2026
getAclCtx() built its cached actionSet for a config request by looking up
only the site-specific /{site}/CONFIG keyword, never the org-level CONFIG
keyword. hasConfigPermission() in the config route ORs both, so a user
holding only the org-level CONFIG rule could actually POST/GET config, but
the actionSet exposed via the X-da-actions/X-da-child-actions headers
lacked write - permanently locking the config editor UI for that user once
the document existed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
adobe-bot
pushed a commit
that referenced
this pull request
Jul 22, 2026
## [1.13.2](v1.13.1...v1.13.2) (2026-07-22) ### Bug Fixes * site write access must not implicitly grant CONFIG write ([#306](#306)) ([9545ea2](9545ea2))
Collaborator
|
🎉 This PR is included in version 1.13.2 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
An author granted with writes access on the content can write the site config. Problem is that the config contains the library and apps extension points: an author can add an external url containing a malicious code - an author would then open the library and apps and auth token might leak.
One mitigation is to only allow trusted users to edit the site config and secure it by default (read only which is required for features to work).
This is a breaking change and we might advertise it as soon as it is merged. Instructions to authors would be to ask permissions to their org owners who would add the
/site/CONFIGwrite entry to the org config.Summary
/site/CONFIGwas reachable via any/site/**or/site/+**write rule, so anyone with recursive write on site content could also write the site's config.getUserActionsnow caps actions toreadwhen a match against a CONFIG keyword target (CONFIGor/{site}/CONFIG) comes from a wildcard/recursive rule rather than a rule targeting the keyword itself.CONFIG(org) or/{site}/CONFIG(site) keyword withwritein org config.Test plan
npm run lintnpm test(476 passing)test/utils/auth.test.js— flipped the assertion that documented the old wildcard-write-leak behavior, added a case proving explicit/mysite/CONFIGwrite rules still grant write