Security Policy

1. Introduction

PrestaSAV places the utmost importance on the security of its users' data. As a SaaS application handling sensitive information — including PrestaShop API credentials, email server credentials and customer communications — security is embedded at every layer of our architecture.

This document describes the technical and organisational measures implemented to protect your data.

2. Data Encryption

2.1. Encryption at Rest

• AES-256-GCM encryption for all stored credentials (PrestaShop API keys, IMAP/SMTP passwords).
• Per-tenant derived keys — Each tenant's credentials are encrypted with a unique derived key, ensuring that a compromise of one tenant's data cannot affect another's.
• bcrypt password hashing — User passwords are hashed using bcrypt with an appropriate cost factor. Passwords are never stored in plain text.

2.2. Encryption in Transit

• SSL/TLS for all communications between users and the application.
• Secure connections (TLS) for IMAP and SMTP communications with email servers.
• HTTPS-only API endpoints for all PrestaShop Webservices and third-party API calls.

3. Secure Architecture

• Multi-tenant isolation — PostgreSQL row-level security (RLS) ensures complete data isolation between tenants. Each tenant can only access their own data at the database level.
• Containerised deployment — The application runs in Docker containers, providing process isolation and reproducible environments.
• Isolated internal network — Backend services, database and cache communicate over an internal network that is not exposed to the public internet.
• Minimal attack surface — Only the necessary ports and endpoints are exposed. All internal services are firewalled.

4. Access Controls

• JWT authentication with configurable token expiration, ensuring sessions are time-limited.
• Role-based access control (RBAC) — Two roles are available: administrator (full access) and agent (limited to assigned tickets and actions).
• Protected REST API — All API endpoints require valid authentication. Unauthenticated requests are rejected.
• No direct database access — All data access is mediated through the application layer. No external database connections are permitted.

5. PrestaShop Integration

• Read-only by default — PrestaSAV accesses the PrestaShop Webservices API in read-only mode. No data is modified on the store unless explicitly configured otherwise.
• No data modification — Customer records, orders, products and other store data are never altered by PrestaSAV under standard operation.
• Encrypted API key storage — PrestaShop API keys are encrypted with AES-256-GCM before storage and decrypted only at the moment of use.
• Optional order status update — An optional feature allows updating order statuses in PrestaShop. This requires the merchant to explicitly grant PUT permission on the /api/orders endpoint and enable the feature in the PrestaSAV configuration.

6. Artificial Intelligence

• AI model: PrestaSAV uses Claude Sonnet 4 by Anthropic for ticket classification and response generation.
• Minimal data transmission — Only the strictly necessary data is sent to the AI API: ticket content (email subject and body) and relevant order context. No credentials or sensitive account data are ever transmitted.
• No Anthropic-side storage — Anthropic does not store the data sent via the API for model training or any other purpose beyond providing the immediate response.
• Human validation mandatory — All AI-generated responses must be reviewed, edited if necessary, and explicitly approved by a human agent before being sent to the customer. The AI never sends replies autonomously.

7. Backups

• Daily automated backups of the entire PostgreSQL database.
• 30-day retention — Backups are retained for 30 days, allowing point-in-time recovery if needed.
• Encrypted backups — All backup files are encrypted at rest.

8. Monitoring and Logging

• Structured logging — All application events are logged in a structured format for traceability and audit purposes.
• Uptime monitoring — Continuous monitoring of service availability with automated alerts.
• Anomaly detection — Alerts are triggered for unusual patterns such as abnormal login attempts, API error spikes or unexpected resource consumption.

9. Incident Management

• Documented response procedures — A formal incident response plan is in place, covering detection, containment, eradication, recovery and lessons learned.
• 72-hour notification — In the event of a personal data breach, affected users and the relevant supervisory authority (CNIL) will be notified within 72 hours, as required by the GDPR (Article 33).
• Post-mortem analysis — Every significant incident is followed by a detailed post-mortem to identify root causes and implement corrective actions.

10. Security Updates

• Regular dependency audits — All third-party dependencies are regularly audited for known vulnerabilities using automated tools.
• Critical patches within 48 hours — Critical security vulnerabilities are patched and deployed within 48 hours of disclosure.
• Continuous integration — Security checks are integrated into the CI/CD pipeline to catch issues before deployment.

11. Vulnerability Reporting

If you discover a security vulnerability in PrestaSAV, we encourage you to report it responsibly.

Please contact us at: [email protected]

We are committed to the following principles:

• Acknowledging your report within 48 hours.
• Keeping you informed of the remediation progress.
• Not taking legal action against researchers who report vulnerabilities in good faith and follow responsible disclosure practices.

Please do not publicly disclose vulnerabilities until we have had the opportunity to investigate and address them.

12. Review

This Security Policy is reviewed and updated at least once per year, or more frequently if warranted by changes to the Service, the threat landscape, or applicable regulations.