Const Dashboard
You build a const dashboard by storing fixed view settings in an immutable object. This approach keeps your admin panel layout and queries consistent across every user session. Engineering teams often bind this setup to shared database keys or broad backend roles. When those roles have too much power, one bad query can expose private records. A single mistake can also change live data across your whole system. How a const dashboard works in your app In many web apps, teams define their main v
GitLab Security Dashboard: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build a const dashboard by storing fixed view settings in an immutable object. This approach keeps your admin panel layout and queries consistent across every user session. Engineering teams often bind this setup to shared database keys or broad backend roles. When those roles have too much power, one bad query can expose private records. A single mistake can also change live data across your whole system.
How a const dashboard works in your app
In many web apps, teams define their main view as a constant object. This object holds the chart types, data sources, and action buttons for the screen. Because the object is constant, the app code cannot alter the layout at runtime. The front end reads this fixed map and renders the exact same widgets every time.
To fill those widgets with data, the backend runs queries tied to each panel. Teams usually set up a single service role so the app can read tables. When a user logs in, the app checks their basic role in the system. If the check passes, the backend runs all the dashboard queries using that shared key.
This pattern is fast to build and easy to keep in version control. Developers review changes to the view layout just like any other code change. It keeps the user interface clean and predictable for everyone on the team. Each widget knows what data to fetch and how to show it on screen.
What native roles solve and what they miss
Native app roles do a good job of deciding who can open a page. You can check a user group and hide the admin view from guest accounts. Role checks also let you disable action buttons for people who only need read rights. This stops casual users from clicking things they should not touch in the app.
Still, page roles only check who logs in at the start of a session. They do not inspect what individual database queries or commands do in flight. Because the backend uses a shared service key, every query runs with full power. If a widget accepts user input for filtering, a bad filter can pull extra rows.
Native roles also fail to filter out sensitive columns inside a valid query result. A support agent might need to see an orders table on the main screen. When the query runs, it returns emails, phone numbers, and card numbers too. Static role checks cannot rewrite those matched fields in results before they reach the screen.
GitLab Security Dashboard: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why static views still need runtime checks
Locking down the front end code does not lock down the data pipeline. Even with a fixed view, requests still travel from the app to your core databases. If an attacker steals a session token, they can trigger those backend routes directly. The database only sees the trusted app key, not the real person behind the click.
Auditing also becomes hard when every dashboard request uses the exact same database role. Your database logs will show thousands of reads coming from one generic app user. When an incident happens, you cannot tell which team member ran a specific query. You need a way to tie every single statement back to a real user identity.
Teams also struggle when an admin panel includes buttons that run system scripts. A static role might let an engineer click a button to restart a broken worker. Without fine controls over the command itself, that script runs with broad host permissions. Safe operations require checking every single command and query right when it runs.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why do teams define a dashboard as a constant object?
Storing view settings as a constant stops runtime code from changing the page layout. It makes the screen easy to test, review in git, and keep stable.
Can front end role checks protect backend database queries?
No, front end checks only hide buttons and screens inside the web browser. You must check permissions on the backend before any query runs against your data.
How can we stop dashboard queries from leaking private fields?
Use data masking to rewrite matched fields like emails and card numbers in results. This lets teams view the dashboard while keeping raw private data off the screen.