A custom data dashboard cannot rely solely on a packaged product's default roles. Map the customer's identity system, organization, data classifications, API gateway, databases, fixed terminals, and operations policies to pages, APIs, row and column data, exports, sharing, and logs. Then test unauthorized access, expiration, failures, and recovery with real role accounts.
Packaged software may provide basic permissions. Custom delivery must apply the same authorization boundary to the customer's actual identity system, business APIs, data services, pages, fixed terminals, and audit trail. Acceptance cannot stop at checking whether a button is hidden.
Built-in BI permissions usually govern users, folders, datasets, pages, and actions inside that product. A custom dashboard may also pass through enterprise single sign-on, business APIs, an API gateway, database views, caches, export services, share links, and fixed displays. Configuring only the product's roles may leave other routes with broader data access or ways around the same rules.
First inventory existing accounts and organizational structure, data classification, API authentication, terminal use, and log platforms. Then decide what permissions can be inherited, what must be mapped through APIs or controlled views, and what needs separate authentication or audit. This is not about rebuilding the permission system; it keeps the existing rules consistent across frontend, backend, data, and operations.
Acceptance should use the customer's real role model, not only two demo accounts called “administrator” and “user.” Test pages, APIs, drilldowns, exports, sharing, and logs for executives, department heads, duty staff, external partners, display terminals, and system administrators to demonstrate that the custom boundaries actually work.
Do not define only “administrator” and “ordinary user.” List actual users, such as executives, department heads, duty staff, operations staff, display terminals, and system administrators. For each, define accessible pages, organization or area data, and actions such as viewing, filtering, exporting, configuring, publishing, and account management.
OWASP's Authorization Cheat Sheet recommends least privilege and deny by default. Hiding a frontend button is no substitute for backend authorization. New pages, APIs, and data scopes should receive explicit permission settings rather than opening automatically to every signed-in user.
Access to a page does not grant access to every department, project, or region. APIs must return data according to the user's identity and allowed scope. Exports, detail drilldowns, and share links should follow the same rules. A showroom or command-center terminal may use a dedicated, limited account, never a shared administrator account.
| Event type | Typical records | Important considerations |
|---|---|---|
| Identity and permissions | Failed sign-ins, account activation/deactivation, and changes to roles or data scope | Record actor, time, object, and result |
| Data actions | Exports, bulk queries, settings changes, and manual data corrections | Do not write entire sensitive records into logs unnecessarily |
| System administration | Changes to API settings, thresholds, published pages, and scheduled jobs | Retain before/after values or link to a version |
| Security exceptions | Denied access, API failures, logging outages, and unusual traffic | Identify who is alerted and how they respond |
OWASP's Logging Cheat Sheet explains that application logs should serve security and operational needs while accounting for access control, integrity, sensitive content, and retention. More logs are not inherently better; define fields, viewing rights, and retention by purpose.
First ask whether the page really needs personal information, contact details, exact locations, financial details, or equipment-control information. If aggregates answer the question, do not show individual records. When details are essential, mask them by role, narrow scope, or move them to a controlled detail page. Consider screenshots, screen casting, exports, and browser caches too.
Download the dashboard roles, multitenancy, and audit acceptance matrix (Chinese) to record pages, row and column scope, view/export/edit rights, sensitive-field handling, terminal limits, log events, and unauthorized-access tests for every role. If group companies, regions, subsidiaries, or external partners share a cockpit, also review management cockpit permissions for a corporate group to check tenant and organizational data isolation. The matrix supports project verification; it does not replace graded cybersecurity, personal-information, or sector-specific assessments.
| Control area | Implementation check | Negative test | Evidence and owner |
|---|---|---|---|
| Identity and roles | Account source, role mapping, deactivation, sessions, credential rotation, and fixed-terminal purpose | Disabled accounts, expired sessions, low-privilege users, and old share links cannot widen access | Account list, role approval, sign-in and denial logs; identity administrator confirms |
| APIs and data | Pages, APIs, rows and columns, tenants, sensitive fields, and drilldowns share one authorization boundary | Changing URL, parameters, organization, export filters, or multi-step context cannot bypass permissions | Permission matrix, request log, and data comparison; system and data owners confirm |
| Export, sharing, and terminals | Export formats, share expiry, caches, screenshot risk, and terminal management are in scope | Expired links, unauthorized exports, and restricted terminals cannot reach the admin area | Link settings, terminal policy, test screenshots, and remediation log; business owner confirms |
| Logs and recovery | Events, fields, viewing rights, integrity, retention, alerts, capacity, and backups are defined | Simulate logging outage, full disk, API failure, and recovery; check actual notification and records | Log samples, monitoring alerts, and recovery records; security and operations owners confirm |
The least-privilege, deny-by-default, and authorization testing methods here mainly draw on the OWASP Authorization Cheat Sheet; event selection, fields, sensitive-data exclusion, protection, and verification for application logs draw on the OWASP Logging Cheat Sheet.
NIST SP 800-53 Rev. 5 includes access-control and audit controls that can supplement review, but does not automatically establish compliance for a project in China. Whether graded cybersecurity protection, personal-information rules, or sector-specific requirements apply should be assessed by the system owner, security team, and qualified specialists against system classification, data types, deployment network, and regulatory duties.
Beijing Hongshan Technology Co., Ltd. prepared this article from dashboard discovery, implementation, and acceptance scenarios. Cited sources explain general control methods; they do not imply OWASP, NIST, or any other organization's endorsement of this site, project plans, or delivery. To report an error, use the contact details in the site content statement (Chinese).
Usually yes. Packaged BI permissions mainly constrain objects inside the product. A custom dashboard may also pass through SSO, an API gateway, business services, database views, exports, sharing, and fixed terminals. Identify inherited permissions, add cross-system mapping, and use real roles to test frontend, API, data, and log boundaries together.
Usually yes. Identity and permissions should reflect users, data sensitivity, and permitted actions. The intranet boundary does not replace application-level access control.
Depending on risk, log at least failed sign-ins, permission changes, settings updates, exports, and admin actions. Project policies determine whether ordinary page views are logged and for how long.
Give each fixed terminal a dedicated limited-purpose account. Restrict pages and data, avoid high-privilege shared administrator accounts, and define credential rotation and terminal management.
Applicability and level should be determined by the system owner, security team, and relevant specialists in light of the business, data, network, and regulatory context; the page type alone cannot decide it.
Related service:Custom data visualization dashboards (Chinese). Continue reading:Custom dashboards versus packaged BI, Secondary development, embedding, or independent custom build, Management cockpit permissions for corporate groups, Connecting enterprise dashboard data, Maintaining enterprise dashboards after launch, Common dashboard acceptance gaps.