Platform engineering8 min read

Designing Secure Role-Based Platforms Beyond the Login Screen

Authentication answers who a user is. A production platform must also decide what that user can read, change, purchase, approve, and administer—across every database query, file, server operation, and interface.

By Auztec Innovations

Treat authorization as a system, not a page guard

Hiding a button or redirecting a user away from an admin page is useful interface behavior, but it is not a security boundary. Authorization must be enforced where data and privileged operations live.

A role model should describe capabilities in business terms: which records a family, specialist, learner, support agent, or administrator owns; which transitions each role can initiate; and which operations require additional assurance.

Enforce ownership close to the data

PostgreSQL Row-Level Security can make access rules part of the database rather than relying on every caller to remember the right filter. Policies should be explicit, narrow, and tested from the perspective of every supported role.

File storage needs the same discipline. Public previews and private purchased or clinical files should not share an access model simply because they belong to the same feature.

  • Default to no access until a policy grants it.
  • Separate public, private, and privileged storage paths.
  • Test representative read and write operations for every role.
  • Keep administrative bypasses server-side and auditable.

Keep money and scoring server-authoritative

Values that affect money, entitlement, assessment results, or payouts should not be trusted simply because the browser submitted them. The server should derive totals, eligibility, and state transitions from authoritative records.

In marketplace workflows, snapshotting the applicable commission or commercial rule at the time of a transaction protects historical accuracy when settings change later. In assessment systems, keeping answer keys and grading logic out of the public client protects integrity.

Make sensitive actions observable

Auditability is part of product quality. Privileged changes, payout decisions, consent records, and security-relevant events need durable timestamps, actors, and before-or-after context appropriate to the risk.

The goal is not to log everything indiscriminately. It is to preserve the events required to investigate, support users, and demonstrate that critical workflows behaved as designed.

Patterns applied in Calm Child Therapy and CertGuru

Calm Child Therapy separates family, psychologist, and administrator experiences, with Row-Level Security, private/public storage separation, consent-gated video workflows, and server-side marketplace integrity.

CertGuru uses Supabase authentication and Row-Level Security, subscription checks at exam start, server-authoritative attempt handling and grading, answer keys kept out of the browser, and additional assurance for privileged administration.

Need to apply this to a real system?

Tell us what you are building and where the current risk or friction lives.