Shop Project - Documentation

Security & Compliance Standards

Documentation of implemented security foundations and the intended legal framework (Switzerland / EU).

🗺️ Stage 0 | 📚 Draft | 📟 2026 06 15 | 📍 Management

Transparency About Development and Legal Status

BRULSIM Shop is publicly available in test operation and remains under development. The technical measures described here are a security foundation, not a guarantee of absolute security, specific availability, or error-free processing; this page also does not replace legal advice. The development status, new functions, and the respective implemented security measures are communicated transparently. Before a full production release, the privacy policy, terms of service, imprint, retention and deletion concept, and the legal duties applicable to the final offering must be professionally and legally reviewed, implemented, and published.

Legal Requirements & AI Act Compliance

Due to the AI Act fully coming into force in 2026, the following strict guidelines apply to handling generative media:

  • Labeling Obligation for AI Media: When artificial intelligence is used for temporary placeholder images, it is transparently declared in the frontend (e.g., via the text "Visualization (AI-generated)").
  • Swiss Imprint & Transparency: Ensuring a legally compliant Swiss imprint for the location Breitenbach (CH) with direct email accessibility.
  • Notice-and-Take-Down: Administrative readiness to instantly remove assets from the server upon valid image complaints to preventively resolve legal conflicts.

Active Core Architecture & Technical Protection

The system follows a strict "Security-by-Design" approach and implements the following protective layers by default in the code foundation:

  • Server & Directory Hardening: Consistent use of restrictive `.htaccess` files to block unauthorized direct access to system folders and core content.
  • Strict Input Validation: Every form input and request undergoes an absolute verification via the modular configuration and validation grid before data is processed further.
  • Consistent SQL Injection Protection: The database class `cDatabase` enforces the exclusive use of prepared statements (PDO) with bound parameters for all relational queries.
  • Cryptographic Password Protection: User passwords are never processed in plain text; instead, they are securely stored in the database using state-of-the-art, native PHP hashing algorithms.
  • Fine-Grained Access Control: Isolation of critical system areas and routes through the dedicated security and authentication services `cSecurity` and `cAccess`.

Planned: Role-Dependent Account Security

The current account protection (email confirmation code + password, no second factor) is deliberately kept low-barrier as a starting point. A targeted hardening is planned for higher roles, without excluding regular users:

  • Stronger protection for sellers, merchants and higher roles: Roles with elevated financial or operational risk (seller, merchant, support, admin) receive additional protection measures (e.g. a second factor) once these are designed.
  • Accessibility for regular users remains mandatory: Regular user accounts must stay simple and accessible, especially for elderly people without a smartphone. No smartphone-only mandatory factor as the sole option for this group.
  • Gradual rollout: Hardening measures are introduced step by step and, where possible, with a transition period, not as an abrupt requirement on the first login after the change.