Scope the publisher to the events it must deliver
The outbox worker needs access to event records and approved destinations. It does not automatically need unrestricted access to the source application's data.
Read articleCobnex blogs / Global
Cobnex blog
AI implementation, software architecture and cloud operations for teams worldwide.
456 articles
Page 17 of 26
Keep idempotency keys inside the correct account scope
A retry key identifies an intention, not a user. Authenticate the caller and scope result lookup so one account cannot retrieve or suppress another account's operation.
Read articleReview access when a response gains new fields
An additive field can expose information to every existing caller. Evaluate its audience and data meaning before treating it as a harmless schema extension.
Read articleCompensation requires its own permission checks
A corrective action can release resources, reverse a commitment or notify a customer. Give it explicit authority rather than treating recovery as an unrestricted system privilege.
Read articleDo not trust the tenant label supplied by the client
A tenant identifier selects a context. The server must establish whether the authenticated caller may use it and whether the target belongs inside it.
Read articleAn event payload is also a data disclosure
Publishing a field creates another accessible copy. Review subscribers, replay tools and retention before adding personal or commercially sensitive information.
Read articleAuthorisation must survive a cache hit
Reusing data must not reuse another caller's authority. Review access checks before and after the point where a cached value enters the response.
Read articleA migration role should not become the application's login
Schema changes may require privileges that ordinary requests do not. Keep that authority scoped to the release process and remove temporary access afterwards.
Read articleRecheck authority when a concurrent change affects permission
A valid session does not guarantee that the requested action remains permitted. Keep the access decision consistent with the state being changed.
Read articleRecreate identity paths before opening the new environment
A migrated application needs the right people and services to reach it with the right authority. Copying data and code does not recreate that access model.
Read articleKeep production authority separate from everyday development
Environment names do not create an access boundary. Verify who can change production, how that authority is obtained and where its use is recorded.
Read articleA restored test database contains real access risks
Recovery drills can create new copies of sensitive records. Apply the destination's access and outbound controls before the restored application starts.
Read articleVerify the recovery region's data and identity boundaries
A second region can introduce new copies, grants and support paths. Review them as part of the service's real operating footprint.
Read articleProtect infrastructure state as operational data
State and plan artefacts can reveal sensitive values and resource relationships. Redacting terminal output does not necessarily remove those values from stored files.
Read articleA pilot cohort does not change the access rules
Feature targeting controls exposure, not authority. The candidate must enforce the same data boundaries as the stable service.
Read articleReliability metrics do not need customer payloads
Measure outcomes with bounded labels and controlled diagnostic links. Keep sensitive request content out of general monitoring systems.
Read articleBilling exports reveal more than a total
Cost data can expose internal projects, resource names and usage patterns. Give teams the detail they need without making the entire organisation's activity broadly visible.
Read articleThe rotation worker needs carefully bounded authority
Automation that changes credentials can be more powerful than the application using them. Restrict its target and keep its own access path auditable.
Read article