Notifications
Clear all
Topic starter
02/08/2026 12:29 pm
TL;DR: Browser-side data masking can hide sensitive values in legacy web applications without backend changes, allowing users to complete tasks such as refunds while limiting overexposure of credit card data, according to Island. The governance lesson is that presentation-layer controls can reduce unnecessary visibility, but they do not replace upstream access scoping or data classification discipline.
NHIMG editorial — based on content published by Island: the case of credit card masking in the browser
Questions worth separating out
Q: How should security teams reduce data exposure in legacy web applications?
A: Security teams should add compensating controls at the point where data is viewed if backend changes are not practical.
Q: When does browser-side masking make more sense than rewriting an application?
A: It makes sense when the application is operationally important, technically hard to change, and exposing more data on screen than users need.
Q: What do organisations get wrong about least privilege in web workflows?
A: They often focus on whether a user can reach an application and ignore how much sensitive data that user can actually see once inside it.
Practitioner guidance
- Map sensitive-field exposure by workflow Identify where legacy applications reveal more data than the task requires, then rank those flows by business impact and regulatory sensitivity.
- Apply selective reveal to exception cases Allow users to unmask one record at a time only when the business process truly requires it, and tie each reveal to a logged action such as a refund or account verification.
- Align masking rules with role and task design Define which fields should be hidden by default for each role, then review whether the visible data still supports operational work without exposing full account identifiers.
What's in the full article
Island's full blog covers the operational detail this post intentionally leaves for the source:
- How the browser masking rule was applied to credit card workflows without changing the legacy application.
- The customer-facing refund workflow details that show how selective reveal supports day-to-day operations.
- Additional examples of safe browsing and content filtering used alongside data masking.
- How the same browser policy was extended to limit distractions during employee break-time internet access.
👉 Read Island's case study on credit card masking in the browser →
Credit card masking in the browser: what IAM teams should notice?
Explore further
02/08/2026 1:27 pm
Browser-level masking is a presentation control, not an identity control. It reduces what a user can see after access has already been granted, which means it complements IAM rather than replacing it. For practitioners, the important distinction is that entitlement scope and data visibility are related but separate problems; both need governance.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who should own browser-level masking controls?
A: Ownership usually sits across IAM, application security, and data governance because the control affects identity, workflow, and sensitive data handling at the same time. The business owner should define what the user needs to see, security should define masking policy, and operations should validate that the rule still fits the task.
👉 Read our full editorial: Browser-side masking for sensitive data in legacy workflows
