Security

Security and data protection

This page describes only measures that are actually implemented in the system. Marketplace recipient data (name, phone, email, address) is processed solely to fulfil orders, stored encrypted and deleted when its retention period ends.

Data location and hosting

Topic	Status
Server location	Netherlands (Amsterdam metro area)
Hosting type	Dedicated bare-metal server — not a public cloud
Hosting provider	[Barındırma sağlayıcısının ticari ünvanı] — network: NovoServe B.V. (AS24875)
Egress IP (marketplace API calls)	185.229.240.40
Where personal data is processed	Only on the server above; sub-processors are listed on a separate page

Encryption

In transit

What it does: All external traffic is HTTPS; TLS 1.2 and TLS 1.3 are accepted, older versions are refused.
How it works: HTTP is redirected to HTTPS with 301; HSTS (1 year) is sent on every response. Calls to marketplace APIs verify TLS certificates.
Problem solved: Eavesdropping and man-in-the-middle attacks.
Technical detail: Internal services (application, database) talk over a private Docker network on the same host; the database port is bound to 127.0.0.1 only and is not reachable from the internet.

At rest (application level)

What it does: Recipient name, phone, email, address and marketplace API credentials are encrypted before being written to the database.
How it works: AES-256-GCM with a random 96-bit IV and 128-bit authentication tag per value; ciphertext is bound to its column (AAD) and cannot be decrypted if moved to another column.
Problem solved: Recipient data being readable if the database or a backup file is compromised.
Technical detail: Storage format: v<version>:base64(iv|tag|ciphertext). HMAC-SHA256 blind index for search; plaintext is never stored.

Key management and rotation

What it does: Encryption keys are not stored in the database; they exist only in a restricted (mode 600) configuration file on the application server.
How it works: Keys are versioned. Rotation adds a new version, raises the active version and runs a re-encryption script for records encrypted with older versions.
Problem solved: Keys leaking together with the data.
Technical detail: Panel API keys are stored as SHA-256 hashes and shown once. User passwords are hashed with bcrypt.

Access control

Role-based access control (RBAC)

What it does: Four roles: Admin, Operations, Read-only, Customer. Every endpoint is protected by a central permission table; anything not listed is denied by default.
How it works: The role is read from the database on every request (token claims are not trusted). Read-only users see recipient data masked only; full view is limited to authorized roles and is logged.
Problem solved: Excessive privileges and unnecessary personal data access.
Technical detail: need-to-know / least privilege · recipient data masked in lists (A*** Y***, *** *** ** 12).

Account-level data scope

What it does: Each customer only sees their own store connections, orders and recipient data.
How it works: All marketplace and order queries are filtered by the session owner's tenant scope; requesting another account's record returns 404.
Problem solved: One seller reaching another seller's data.
Technical detail: Plan scope is also enforced on the product API: trial and product-limited plans only return their allowed product list.

Leavers and role changes

What it does: Account deactivation, role changes and session revocation take effect immediately.
How it works: Deactivation invalidates all sessions, revokes API keys and pauses the user's store syncs. A role change ends all sessions; new permissions apply at next sign-in.
Problem solved: A former employee's access staying open.
Technical detail: Sessions are bound to a token version; once incremented, old tokens are rejected within 30 seconds at most. All actions are written to the audit log.

Authentication

What it does: Password policy: at least 8 characters with upper- and lower-case letters, a digit and a special character.
How it works: Failed sign-ins are rate-limited per IP and account (10 attempts per 15 minutes); a password change ends all other sessions.
Problem solved: Brute-force and credential-stuffing attacks.
Technical detail: Session lifetime 12 hours.

Logging

Internal user queries

What it does: Every list containing recipient data and every full view, plus all mutating actions of signed-in users, are written to the audit log.
How it works: Each record: who (user, role), when, IP, panel page, endpoint, record, request summary and response summary.
Problem solved: Not being able to show who accessed personal data and why.
Technical detail: Records contain no personal data (only field names from request bodies). The table is append-only: UPDATE, DELETE and TRUNCATE are blocked by a database trigger. Retention: 365 days.

External (API) queries

What it does: Every API-key request is logged with key, method, path, status, IP and time.
How it works: Customers see them as 'Recent requests'; admins see them per key.
Problem solved: Not knowing which integration pulled data and when.
Technical detail: Retention: 365 days. The real client IP is taken safely from the reverse-proxy header.

Retention and deletion

Data	Period
Marketplace recipient data (name, phone, email, address)	Permanently deleted 30 days after the order closes; at most 90 days after the order date for orders that never close
Marketplace API credentials	Deleted when the store connection is removed (with listings and orders)
Audit log	365 days
API request log	365 days
Sync log	90 days
Contact form messages	2 years

Incident response and security contact

When a security incident affecting personal data is detected, affected access is shut off immediately (session and key revocation, store sync paused), audit logs are reviewed, and affected customers and the relevant marketplace are notified within 24 hours. Statutory notifications under the Turkish data protection law (KVKK) are made separately.

To report a vulnerability, choose 'Security' as the topic in the contact form. Reports are handled with priority.