Protecting every shop starts with careful foundations.

1. Our security approach

Store Seba is a multi-tenant commerce platform: one service supports multiple independent businesses. Security therefore depends on protecting accounts, correctly identifying the requested shop, enforcing permissions at the server, minimizing access, validating input, and keeping business data separated throughout each protected operation.

Security is an ongoing process. Controls must be reviewed whenever Store Seba adds providers, payment integrations, custom domains, staff capabilities, public APIs, or new ways to process customer information.

2. Accounts and sessions

• Passwords are processed using Argon2id password hashing.
• Session tokens are placed in HttpOnly cookies so ordinary browser scripts cannot read them.
• Production cookies use HTTPS-only transport and SameSite=Lax protection.
• Email verification, password reset, and password-change confirmation flows use purpose-specific records and expiry controls.
• Login, registration, recovery, verification, and related sensitive endpoints apply rate limits.
• Logging out expires the browser's session cookie.

Store Seba must still add and verify production session-revocation monitoring, administrator access procedures, and stronger authentication options such as multi-factor authentication as the platform matures.

4. Application protection

Store Seba validates structured request data, applies authenticated contexts and permission guards to protected APIs, avoids exposing internal failure details in production responses, and uses rate limiting on high-risk public actions such as checkout, order tracking, contact submissions, authentication, invitations, and upload requests.

Security-sensitive changes should be reviewed, tested, and deployed through controlled environments. Before public production, Store Seba must verify HTTP security headers, cross-origin rules, request-forgery protections for every mutation pattern, dependency scanning, error monitoring, and automated security tests against the deployed architecture.

5. Data and infrastructure

• Production traffic must use HTTPS for data in transit.
• Database credentials, signing material, provider keys, and administrative secrets must remain outside source code and be limited by environment.
• Database access should use scoped application roles and restricted functions appropriate to each operation.
• Backups must be encrypted where supported, access-controlled, tested through restoration exercises, and retained under an approved schedule.
• Production logs must avoid passwords, session tokens, private keys, full payment secrets, and unnecessary customer data.
• Provider and administrator access must follow least privilege and be removed promptly when no longer needed.

The final infrastructure provider list, hosting region, encryption-at-rest position, backup targets, recovery objectives, and log-retention periods must be confirmed before making more specific public claims.

6. Upload and media security

Tenant media uploads require account access and the appropriate media permission. Store Seba issues time-limited signed upload instructions and validates supported file metadata before registration and processing. Upload endpoints also apply rate limits.

Production readiness requires confirmed content-type enforcement, file-size limits, image re-encoding, malicious-file handling, private-versus-public storage rules, safe download headers, deletion behavior, and provider-level access restrictions.

7. Operational security

Secure software also depends on disciplined operations. Store Seba's production process should include reviewed changes, separated environments, controlled deployments, dependency and secret scanning, centralized alerts, availability checks, backup verification, access reviews, vulnerability remediation targets, and documented incident roles.

Employees, contractors, and support personnel should receive only the access necessary for their work. High-risk administrative actions should be attributable and reviewed.

8. What owners, staff, and customers should do

• Use a unique password and protect the email account connected to Store Seba.
• Do not share passwords, PINs, one-time codes, recovery links, or session information.
• Invite only authorized staff and give each person the minimum permissions needed.
• Remove former staff promptly and review unexpected changes or activity.
• Keep devices, browsers, and connected services updated and protected.
• Confirm payment and support requests through trusted routes before sharing information.
• Report suspicious access, phishing, exposed information, or security weaknesses promptly.

10. Incident response

When a credible security concern is reported, Store Seba should acknowledge it, preserve relevant records, assess scope and severity, contain ongoing risk, remediate the cause, validate the correction, recover affected services, and notify affected parties or authorities when required. Communication must be accurate and avoid creating further risk.

Before launch, Store Seba must approve named incident owners, severity levels, emergency contact routes, provider escalation, evidence handling, notification decision-making, recovery procedures, and post-incident review.

11. Assurance and roadmap status

Store Seba is not presently claiming ISO 27001, SOC 2, PCI DSS certification, formal penetration-test coverage, or a paid bug-bounty program on this page. Payment providers may have their own compliance responsibilities, but their status does not automatically certify Store Seba.

These claims should be updated only after evidence exists. The immediate production roadmap includes an independent assessment, remediation of findings, infrastructure and access review, recovery testing, monitoring and alerting, incident exercises, and periodic reassessment.