Security Hardening & Governance Controls in the SGSS Medical Fund Portal

The SGSS Medical Fund Portal is a production system built for a community organization to manage medical claims, member contributions, and committee governance. The system replaced manual paper-based workflows that were vulnerable to fraud, accountability gaps, and inconsistent decision-making. It serves real users with real financial transactions, making security a first-order concern rather than an afterthought.

The system handles sensitive financial data (member contributions, claim payouts, fund balances) and governance decisions (committee approvals, member admissions). Key risks identified:

• Unauthorized access to financial operations
• Self-approval of claims by committee members (governance breach)
• Inconsistent claim lifecycle transitions bypassing required approvals
• Lack of accountability for administrative decisions
• Missing audit trail for financial transactions
• Context confusion between member and committee operations

The threat model considered:

• Insider threats: Committee members approving their own claims or accessing unauthorized data
• Privilege escalation: Members accessing committee-level operations through direct URL manipulation
• State manipulation: Claims bypassing required governance workflow steps
• Financial integrity: Duplicate payment submissions or unauthorized fund disbursements
• Audit gaps: Actions taken without traceable accountability

The system uses a Django REST Framework backend with a React TypeScript frontend. PostgreSQL handles persistent storage. The architecture enforces security at multiple layers:

• Backend: Django permission classes, django-fsm state machines, custom governance guards
• API: Token-based authentication, role-based serializers, context-aware viewsets
• Frontend: Mode-based UI rendering, route guards, context isolation
• Database: Row-level permission checks, immutable audit log table

Mode-Based Access Control (MBAC)

The system enforces strict context separation between four operational modes: Member, Committee, Admin, and System. Each mode has its own navigation, permitted actions, and API scope. A user operating in Member mode cannot access Committee operations even if they hold committee-level permissions — they must explicitly switch context, creating a clear audit signal.

Claim Lifecycle State Machine (django-fsm)

All claims follow a rigid, programmatically enforced lifecycle: Draft → Submitted → Under Review → Approved/Rejected → Paid/Appealed. Transitions are guarded by permission checks and cannot be bypassed. Invalid state transitions (e.g., jumping from Draft to Paid) are structurally impossible.

Governance Guards

Hard-coded backend protections prevent self-approval (a committee member cannot approve their own claim), enforce quorum requirements for financial decisions, and validate that the adjudicating user has the correct committee role.

Immutable Audit Log (GovernanceAuditLog)

Every state change, financial transaction, and governance decision is recorded in an append-only audit log with: timestamp, acting user, action type, previous state, new state, and contextual metadata. This log cannot be modified or deleted through the application.

Roles and permissions are handled through Django's permission framework extended with custom committee-specific permissions:

• Members: Can submit claims, view own contribution history, download statements
• Committee Members: Can review claims, vote on approvals, view fund summaries
• Treasurer: Additional permissions for payment processing and financial reconciliation
• Admin: System configuration, user management, audit log access

Each API endpoint validates both the user's role AND their current operating context (mode). Route-level guards on the frontend prevent direct URL access to unauthorized sections, but all enforcement is duplicated on the backend — the frontend is treated as an untrusted client.

During development, several security weaknesses were identified and addressed:

• CSRF token handling was hardened for all state-changing API requests
• Frontend governance guards were synchronized with backend enforcement to prevent UI/backend drift
• Duplicate payment submission prevention was implemented
• Role-based verification restrictions were tightened
• Committee reconciliation workflows were enhanced with notification deep-linking
• Financial transparency features (share capital exposure, KPI dashboard) were added to support governance oversight

Security controls were validated through:

• Automated Django test suites verifying governance rule enforcement
• React component tests verifying mode-based UI isolation
• Manual testing of privilege escalation scenarios (direct URL access, API manipulation)
• Verification that self-approval is blocked at both frontend and backend layers
• Audit log completeness checks ensuring all state transitions are recorded

1. Security enforcement must be duplicated at every layer — frontend guards are UX, not security
2. State machines (django-fsm) transform business rules from "guidelines" into structurally enforced constraints
3. Audit logging should be designed as immutable from day one — retrofitting is far more complex
4. Mode-based access control prevents the most common governance breach: context confusion
5. Financial systems require explicit anti-patterns (no self-approval, no duplicate payments) to be coded as hard guards, not soft warnings