> For the complete documentation index, see [llms.txt](https://docs.enicebakerygh.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.enicebakerygh.com/architecture-and-engineering/security.md).

# Security Controls & Ghana Act 843

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:

| Pillar              | Architectural Threat                                      | Enforced Platform Mitigation                                                                                                         |
| ------------------- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Confidentiality** | Unauthorized access to patron data or payment credentials | Strict RBAC middleware (`AdminMiddleware`), Bcrypt hashing, automatic audit log redaction, TLS 1.3 HTTPS enforcement.                |
| **Integrity**       | Tampering with prices, balances, or order records         | Server-side price resolution from catalog models, `DB::transaction()` isolation, HMAC webhook verification, CSRF token validation.   |
| **Availability**    | Denial of Service (DoS) and brute force attacks           | Route-level rate limiting (`throttle:6,1`), background queue processing, health check probes (`/up`), automated Docker auto-healing. |

***

## 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`:

```mermaid
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

| Role                | POS Terminal |  Orders & Dispatch | Catalog & Pricing | Settings & Branding | Financial Reports |
| ------------------- | :----------: | :----------------: | :---------------: | :-----------------: | :---------------: |
| **`super_admin`**   |     Full     |        Full        |        Full       |         Full        |        Full       |
| **`admin`**         |     Full     |        Full        |        Full       |         Full        |        Full       |
| **`manager`**       |     Full     |        Full        |        Full       |      Read-Only      |        Full       |
| **`cashier`**       |     Full     |      POS Only      |     Read-Only     |         None        |        None       |
| **`kitchen_staff`** |     None     | Update Prep Status |     Read-Only     |         None        |        None       |
| **`customer`**      |     None     |   Own Orders Only  |     Read-Only     |         None        |        None       |

### 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:

```php
// 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.enicebakerygh.com/architecture-and-engineering/security.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.