Public and private route separation
Public pages use a separate route layout and do not load the authenticated workspace shell, sidebar state, or private clinical QueryClient.
CliviQue security
Separate public content from authenticated hospital work
CliviQue uses layered controls across browser sessions, route layouts, the same-origin gateway, backend authorization, organization and facility scope, caching, database access, and deployment configuration.
Current architecture
Controls implemented in the web and backend code
These statements describe the current application architecture. They are not claims of a regulatory certification or a guarantee that no security incident can occur.
HttpOnly web sessions
In production, access and refresh credentials are kept in host-bound, Secure, SameSite=Strict, HttpOnly cookies through a same-origin Next.js gateway.
Backend authorization
Protected requests are authenticated and authorized by FastAPI. Browser role and permission values are interface hints, not the source of authority.
Organization and facility scope
Sampled clinical and billing paths resolve organization and facility access on the backend before querying protected records.
Session and cache isolation
Private cached state is cleared on login, logout, identity change, storage change, and cross-tab session events. Remote logout redirects other tabs to login.
Browser and API hardening
The application applies CSP, anti-framing, MIME-sniffing prevention, restrictive referrer and permissions policies, no-store responses, origin checks, and Fetch Metadata validation.
Browser boundary
The public website is not the clinical workspace
Public routes are statically renderable marketing pages. Only authenticated workspace routes load the clinical QueryClient, workspace shell, permission-aware navigation, and sidebar cookie. Production gateway access is restricted to the configured central HMIS hostname.
Public hospital domains are not treated as authorization evidence and should not receive an HMIS-wide cookie.
Web session behaviour
- Actual access and refresh credentials are not stored in localStorage.
- Cross-origin mutations are rejected using Origin and Fetch Metadata checks.
- Sensitive gateway and backend responses use no-store caching directives.
- Unauthorized responses clear the web session cookies.
- Logout and identity changes clear private query state across tabs.
Server-side authority
Protected endpoints resolve the authenticated user and enforce action permissions, subscription entitlements, organization scope, facility scope, and record filters on the backend. Hiding a button alone is never treated as sufficient authorization.
Additional hardening
Fail-closed production configuration
Production startup validation rejects known development secrets, insecure database transport, unsafe redirect and CORS settings, placeholder billing configuration, development migrations, and other explicitly unsafe defaults. API documentation is disabled by default in production.
Authentication endpoints include configurable account-and-IP keyed throttling. Refresh tokens are stored as hashes and rotated by the backend.
Shared responsibility
Hospitals and CliviQue each have security responsibilities
Use individual staff accounts and do not share credentials.
Apply appropriate role assignments and promptly disable departing or suspended users.
Protect workstations, mobile devices, networks, backups, exports, and printed documents.
Train staff on privacy, phishing, safe disclosure, and local clinical record procedures.
Review access, facility configuration, subscription scope, and operational logs regularly.
Meet applicable health, privacy, retention, breach, consent, and professional requirements.
Report a suspected security issue responsibly
Use the contact page and clearly mark the message as a security report. Do not include patient records, passwords, session tokens, secret keys, or unnecessary personal health information in ordinary email. Provide enough non-sensitive detail for safe follow-up.
Guided implementation
Include security in the implementation review
A hospital evaluation should cover account roles, facility scope, deployment hosts, data handling, backups, incident contacts, device security, retention expectations, and responsibilities on both sides.