Question
Private workspace roles vs. link-sharing for collection security
Cig Atlas
0 reputation · 13 Sept 2020, 01:23 UTC
149.6K views1
Loading…
0 reputation · 13 Sept 2020, 01:23 UTC
Private Workspaces allow for granular control by assigning team members to Viewer, Editor, or Admin roles. This ensures the collection remains within the organization's boundary. In contrast, sharing a collection link provides a lower-friction method for external stakeholders without adding them to the workspace, but it relies entirely on the secrecy of the URL.
A significant constraint arises when considering the visibility state of already-published items. Once a collection is published to the API Network, there is no documented mechanism to toggle its visibility between public and private without republishing the entire collection as a new version.
For sensitive collections, role-based access in a private workspace is the stronger default on both counts you raised: it gives you a per-person audit trail and per-person revocation. Link sharing is appropriate only for non-sensitive, view-only material, and disabling the link toggle afterward is damage control, not real mitigation.
Private workspaces win decisively. Because every action is tied to an authenticated identity with an assigned role (Viewer, Editor, Admin), workspace activity logs can show who viewed, edited, exported, or changed permissions on a collection. If something leaks, you can narrow the suspect set to named members and check the log.
A shared link is anonymous by design. At best, logs may show that "the link" was accessed — not by whom. If the URL is forwarded, pasted into a chat, or captured in a proxy log, you have no way to attribute the access. For tracking accidental exposure, that is the fundamental difference: roles give you accountability, links give you a dead end.
Only partially, and you should treat it as containment rather than a fix:
So if a link to a sensitive collection has leaked, the correct sequence is: disable the link, rotate any credentials the collection exposed, then review logs for access during the exposure window.
Your observation about the API Network is consistent with how publishing generally works: a published public artifact is a snapshot, and changing its visibility typically means delisting or republishing rather than toggling a switch. Treat publication as a one-way door — review the collection for secrets before publishing, because anything already public should be considered permanently exposed (rotate any credentials it contained).
Exact capabilities — guest seats, link regeneration, per-link expiry, what a link holder can fork — vary by product version and pricing tier, so confirm on your own plan:
One caveat worth stating plainly: even in a private workspace, Editors can usually export or copy collection contents. Roles shrink your exposure and give you an audit trail — they do not eliminate insider leakage.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 13 Sept 2020, 09:40 UTC
To build on the discussion of audit trails, it is critical to distinguish between the collection structure and the request data. Even with a Viewer role in a private workspace, users can often see the values of 'Initial Value' fields in request bodies or headers if they aren't properly parameterized.
A common security failure occurs when teams use shared links or Viewer roles but hardcode API keys or tokens directly into the request examples. Because these are stored as part of the collection definition:
To verify your current exposure, check if sensitive data is stored in the Initial Value column of your environment variables or hardcoded in the request examples. For true security, only Current Value (which is local to the user and not synced) should hold secrets.
postman