Security
1. Introduction and scope
This Security Statement summarises the technical and organisational measures (TOM) Goup Space Sp. z o. o. applies to protect personal data and other data processed via the Platform.
The Operator applies the general principle of Art. 32 GDPR: "reasonable technical and organisational measures proportionate to the risks", taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing.
Operator: Goup Space Sp. z o. o., contact info@pages.otack.eu. Related documents: Privacy Policy, Data Processing Agreement.
2. Encryption in transit
All traffic between the User's browser and the Platform is encrypted via HTTPS / TLS (TLS 1.2 or higher).
The session cookie WGSESS_{port} is set with the Secure flag in production (HTTPS-only) and HttpOnly (not accessible from JavaScript), with SameSite=Lax for CSRF mitigation.
3. AI keys — precise posture (NOT zero-knowledge)
This section describes our handling of the User's API keys to third-party AI providers. The wording is identical in meaning to Privacy Policy §9.
The User's AI provider API key is encrypted in the browser using PBKDF2 + AES-256-GCM (Web Crypto API). The encryption password is never transmitted to the Operator.
The encrypted blob is stored in users.ai_keys_blob (Account mode) or in the browser's localStorage (File mode). The Operator cannot decrypt either storage.
When the User makes an AI request, the key is decrypted in the browser and sent to the Operator over TLS in the X-AI-API-Key HTTP header. The key is held in PHP memory only for the duration of the single AI request and is then discarded.
The key is never persisted in readable form on Operator infrastructure and is never logged (the generation_log payload-capture flag captures the prompt and the response only, never the key).
For asynchronous generation jobs placed in the internal Redis job queue, the key is re-encrypted using AES-256-GCM (JobEncryptor) before being placed on the queue, and is erased from the queue after the worker has processed the job.
The Operator does not operate a true "zero-knowledge" architecture: the key passes through the Operator's server in plaintext for the duration of one request. However, the Operator never stores the key in readable form and never logs it.
4. Passwords
User passwords are never stored in plaintext. Passwords are hashed using bcrypt (PASSWORD_BCRYPT via PHP's password_hash()) with a per-password salt; the Operator does not retain the original password.
Password-reset and email-verification tokens are random, single-use, and expire on a short window.
5. Access control and segregation of admin from user authentication
The Platform separates user authentication (table users) from administrative authentication (table admins). User session keys and admin session keys are distinct.
Administrative actions are written to an immutable audit log (table admin_audit_log) including the acting admin, the action, the entity, and any state change.
Application-level rate limiting is enforced on authentication endpoints to mitigate brute-force attempts.
6. Anti-CSRF and request integrity
All state-changing HTTP requests (POST and similar) are protected by an anti-CSRF middleware that validates a 32-byte random token bound to the User's session.
7. Queue payload encryption
The internal job queue (Redis-backed) carries sensitive payloads — AI API keys, SFTP deploy credentials, and similar.
All sensitive fields in queue jobs are encrypted using AES-256-GCM (JobEncryptor) with a random per-payload IV and AEAD tag before being placed on the queue.
Sensitive fields are stripped from any job that is moved to the dead-letter queue.
8. Payment data — outside our scope
Card data (PAN, expiry, CVV) is collected and processed exclusively by Stripe Payments Europe Ltd. (1 Grand Canal Street Lower, Grand Canal Dock, Dublin 2, Ireland).
The Operator never receives, stores or processes card data. The Operator retains only the metadata needed for reconciliation (order reference, amount, currency, status, provider order id, buyer email).
9. Backups, monitoring and incident response
The Operator performs regular database backups to enable recovery in the event of data loss or corruption. (Specific RTO/RPO targets are NOT published in this Statement.)
The Operator monitors application and infrastructure logs for security events.
In the event of a personal-data breach the Operator follows GDPR Art. 33 (notify the supervisory authority — Prezes UODO — within 72 hours where the breach is likely to result in a risk to the rights and freedoms of natural persons) and Art. 34 (notify affected data subjects without undue delay where the breach is likely to result in a high risk).
10. User responsibilities and contact
The User is responsible for:
- keeping their account password confidential and using a unique, strong password;
- protecting their AI-keys encryption password (the Operator cannot recover it);
- configuring their published Generated Sites with appropriate security (privacy notice, cookie banner, HTTPS).
Reporting a security concern: please contact info@pages.otack.eu with the relevant details. The Operator considers and responds to reports per its complaint procedure (see Payment & Refund Terms §10).
Effective date: 2026-05-20. The English version is the master; in case of conflict the English version prevails.