René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Auditing permissions","articleBody":"### What is the problem this feature will solve?\n\nSetting permissions can help protect your resources, but adding these requirements to an existing project can take trial and error as you figure out which permissions you need to grant. **Auditing** can make this easier.\n\nWhen a rule is audited, it means it isn't enforced but it _is_ monitored. This allows you to test it without breaking code.\n\nAfter a user has done an audit, they could see what resources were and weren't accessed and set **enforced** permissions accordingly.\n\n### What is the feature you are proposing to solve the problem?\n\nAn \"audit mode\" could be added to the permissions API to allow permission violations to be logged but not prevented. It could be part of the command-line flag:\n```sh\n--permission=audit --allow-fs-read=.\n```\nWith this configuration, read operations outside the CWD would be logged.\n\n### What alternatives have you considered?\n\nOne problem with an audit mode is that you cannot **both enforce and audit** different sets of permissions at the same time. An alternative would be to use separate flags for auditing, kind of like how the `Content-Security-Policy-Report-Only` HTTP header works.\n\nSay you are currently restricting access to outside write operations but want to test stricter rules. You could do something like this:\n```sh\n--permission --allow-fs-read=* --allow-fs-write=. --audit-permission --audit-allow-fs-read=. --audit-allow-fs-write=dist\n```","author":{"url":"https://github.com/DNin01","@type":"Person","name":"DNin01"},"datePublished":"2025-09-19T19:02:43.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/59935/node/issues/59935"}