Application Security Architecture & Ghana Compliance

This document details the security controls, authentication safeguards, authorization policies, credential isolation, and legal data protection mechanisms implemented across the Eniceberny platform.

1. CIA Triad Security Enforcement Matrix

The platform enforces the classic Confidentiality, Integrity, and Availability (CIA) triad across all software layers:

2. Authentication & Session Security

2.1 Password Hashing & Key Derivation

• Passwords are encrypted using standard Bcrypt with dynamic cost factors (Hash::make()).
• Plaintext passwords are never stored, logged, or serialized.
• On login, hashes are automatically re-evaluated and upgraded if framework work factors increase.

2.2 Secure Session Management

• session.regenerate() is executed upon successful login and registration to eliminate session fixation vulnerabilities.
• Session cookies are strictly configured with:
  • HttpOnly: Prevents client-side JavaScript access via XSS.
  • SameSite=Lax: Mitigates Cross-Site Request Forgery (CSRF).
  • Secure: Transmitted exclusively over encrypted HTTPS connections in production.

2.3 Email OTP Verification Engine

To prevent spam accounts and ensure valid patron communication channels:

• New customer registrations trigger an automated 6-digit cryptographic verification code dispatched via VerifyEmailOtpMail.
• Expiry Window: OTP tokens expire after 15 minutes.
• Cooldown Throttling: A 60-second cooldown is enforced between resend attempts to prevent email flooding.
• Change Email Feature: Patrons can correct typographical errors in their email address directly from /verify-otp via the "Change Email Address" modal.

3. Role-Based Access Control (RBAC) & Granular Permissions

Access to system capabilities is governed by a hierarchical role model defined in App\Enums\UserRole:

graph TD
    SuperAdmin[super_admin: Full System & Financial Access] --> Admin[admin: Operational & Catalog Management]
    Admin --> Manager[manager: Daily Sales, Staff & Inventory]
    Manager --> Cashier[cashier: POS Terminal & Walk-in Orders]
    Manager --> Kitchen[kitchen_staff: Kitchen Queues & Dispatch]
    Customer[customer: Storefront Ordering, Invoices & Addresses]

3.1 Role Capabilities Matrix

3.2 Granular Permission Overrides

Individual staff accounts support granular capability flags (e.g. manage_settings, manage_users, manage_pos, view_reports, manage_catalog), allowing fine-grained delegation without elevating full administrative roles.

4. Ghana Data Protection Act 2012 (Act 843) Compliance

The platform is designed to adhere to the statutory data protection principles mandated by Ghana's Data Protection Act, 2012 (Act 843):

4.1 Legal Principles Implemented:

1. Consent & Purpose Specification (Section 20):
   • Patrons explicitly consent to data processing upon account creation.
   • Data collected (Name, Phone Number, Delivery Address) is used exclusively for order fulfillment and customer service.
2. Data Minimization (Section 21):
   • Only data necessary for culinary production and delivery logistics is gathered. No unnecessary biometric or tracking data is requested.
3. Data Quality & Accuracy (Section 22):
   • Patrons can view, edit, and update their profile, telephone numbers, and delivery addresses at any time via /account.
4. Right to Erasure & Rectification (Section 33):
   • Customers have the right to request deletion of their account profile. Historical financial orders are anonymized to maintain statutory tax audit records while purging personal identifiers.
5. Security Safeguards (Section 28):
   • Data at rest is encrypted within managed PostgreSQL instances.
   • Communications are encrypted via TLS 1.3.

5. Automated Sensitive Data Redaction in Audit Logs

The AuditLog engine automatically sanitizes all recorded state changes to prevent credential or payment information leakage:

// app/Models/AuditLog.php
protected static array $redactedKeys = [
    'password',
    'password_confirmation',
    'current_password',
    'token',
    'remember_token',
    'secret',
    'api_key',
    'paystack_secret_key',
    'paystack_public_key',
    'card',
    'cvv',
    'pin',
];

When an administrator updates settings or user accounts, any matching keys in the request payload are replaced with [REDACTED] before saving to the database.

6. Input Validation & Defense in Depth

• SQL Injection Prevention: All queries utilize Eloquent ORM or parameterized bindings (DB::select('... WHERE id = ?', [$id])).
• Cross-Site Scripting (XSS): Blade templates enforce automatic HTML entity encoding ({{ $untrustedInput }}). Raw unescaped output ({!! ... !!}) is strictly prohibited on user-supplied content.
• CSRF Token Validation: Every state-altering HTTP request (POST, PUT, PATCH, DELETE) requires a verified @csrf token or X-CSRF-TOKEN header.
• Rate Limiting:
  • throttle:6,1 applied to all authentication, login, and OTP verification endpoints.
  • throttle:10,1 applied to public contact forms and catering inquiry submissions.