Security Audit & Protections

Last Updated: May 18, 2026

iAccountApp is engineered to ensure robust data security, session isolation, and operational confidentiality. This Security Audit details the proactive protections embedded across our application layers.

1. Sandbox Model & Multi-User Segregation

We enforce strict boundary checks to ensure total privacy for every focus group participant:

Parameterized Scopes: All database queries (such as fetching transactions, goals, categories, and smart rules) strictly bind the active authenticated `user_id` from the PHP session.
No Global Exposure: Custom categories stored in the `user_categories` table are scoped strictly to the current user's profile, preventing leaky leakage between accounts.
Memory Cleansing: All transaction records are held in standard SQL databases with unique, indexed key mappings to block collisions.

2. CSRF Token Safeguards

To eliminate cross-site request vulnerabilities, the system implements a rigid cookie-to-header token verification model:

Every non-GET post action (category edits, profile updates, rules saving) requires a valid `X-XSRF-TOKEN` HTTP header.
The system dynamically generates a secure, randomized CSRF key per session and validates it against incoming headers using `Sanitise.php` middleware.
If a browser request lacks this authenticated token, the system blocks execution immediately, returning a standard 400 validation error banner to prevent malicious actions.

3. Two-Factor Authentication (OTP Verification)

 2FA SECURITY COVERAGE: Registration and logins require verification using dynamic One-Time Passwords (OTP). Upon submitting credentials, the system generates a secure, timed verification code, which is recorded locally to complete the authentication loop securely.
 

4. API Security & Input Sanitization

Every interface communicating with external integrations or third-party models is subject to standard protective filters:

AI Chat Parameters: Conversational questions submitted to the forensic AI chat module are sanitized to prevent SQL injection or system prompt injection.
File Upload Ingestion: Drag-and-drop statements (PDF/CSV) are parsed inside a isolated local sandbox. The system detects header maps and currency splits while cleaning any unescaped inputs.

5. Continuous Integration Audits

We perform regular security posture checks on our local environment including: verifying dependency locks inside `composer.lock`, scanning for unescaped Blade template outputs, and validating local file-system boundary permissions to prevent unauthorized script injections.