Hiding a sensitive field on one form is not the same as restricting access to it. The value may still appear in an export, API response, search result or notification. Plan permissions around data and actions, not only screen layouts.
Related service: CRM, ERP and web application development- 01Identify the business need for the field.
- 02List allowed reads and changes.
- 03Apply rules across access paths.
- 04Test roles and indirect disclosures.
- 05Review permission changes over time.
SECTION 01
Describe access in business terms
A sales representative may need a contact number but not a private account review note. A team manager may see that note without being allowed to edit its approved status. Write these distinctions as concrete examples, including temporary cover and users who belong to more than one team.
Keep the field inventory small enough to maintain. Excessively intricate permissions can confuse staff and make testing expensive. Sometimes a separate restricted record is clearer than dozens of special cases on one form. OWASP authorization guidance supports checking permission for each requested action; the actual field policy must come from your organization's approved operating needs.
SECTION 02
Illustrative example: a restricted account note
Suppose a CRM includes an internal account review note. Staff may see the ordinary account page but only designated reviewers may read the note. A dashboard shows that a review is pending without disclosing its content. This is a hypothetical permission design, not a claim about a delivered security system.
Now test the account export and search preview. If either includes the note, the form restriction has failed its purpose. Also consider historical versions and notification templates. A permitted reviewer should be able to correct the note with a recorded reason, while a salesperson can request review without gaining direct editing authority.
SECTION 03
Test prohibited actions using ordinary accounts
Prepare two sample users with different rights and a set of known restricted records. Ask the agency to demonstrate direct API reads, bulk exports, search, saved reports and changed-role sessions. An administrator's successful demonstration cannot prove that ordinary users are properly restricted.
Use existing CRM field-security features where they cover the required paths. If custom controls are needed, document where enforcement occurs and who maintains the tests. Logging can help investigate access changes, but avoid copying the sensitive field into unrestricted logs. The first release should implement a few clearly justified restrictions completely instead of adding many partially enforced visibility rules.
SECTION 04
Frequently asked questions
Can we secure a field by hiding it with CSS?
No. The data may still reach the browser or another interface. The system must enforce the permission before returning or changing the value.
Should exports have separate permissions?
Yes, define whether a role can export and which fields it receives. An export should not bypass record or field restrictions.
Do activity logs need the full old value?
Not always. Record enough for the agreed review purpose without creating another broadly accessible copy of sensitive content.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Authorization guidanceOWASP Foundation
- Application logging guidanceOWASP Foundation
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy