Security at ShopBoost

ShopBoost is a SaaS dashboard for online sellers in Brazil. This page describes the security posture of the current MVP as it is today, without making forward-looking claims. We will keep this page in sync with the controls actually implemented in production.

Authentication and sessions

• Access to the dashboard is protected by an authenticated session. Passwords are stored as bcrypt hashes — never in plain text.
• Sessions are carried in httpOnly, Secure, SameSite=Lax cookies signed (HS256) with a secret stored in the server environment.
• Logging out invalidates the session cookie on the client.

Tenant isolation

• ShopBoost is multi-tenant. Every customer-owned database row carries an organization_id. Application code filters queries by the caller’s organization so that data from one seller is not visible to another.

Store integration

• Sellers connect their store through a secure platform authorization flow (OAuth). ShopBoost never asks for, stores, or transmits the seller’s platform password.
• OAuth state values are generated server-side, stored in a dedicated table with a short expiration, single-use, and validated on callback. Expired or replayed states are rejected.
• Access and refresh tokens issued by the platform are stored in a dedicated tokens table, encrypted at rest using AES-256-GCM with a key sourced from the server environment. Tokens are never returned to the browser and never written to application logs.
• The current MVP is read-focused. ShopBoost does not perform product deletion, product modification, delivery status changes, promotion modifications, or any other write action against the connected store. Any future expansion of the scope will require fresh consent from the seller.

Secrets management

• Secrets (database URLs, session signing key, token encryption key, platform app credentials) are stored as environment variables on the hosting platform and are not committed to source control. The repository’s .env.example ships only with placeholder values.
• The platform app secret is used only on the server side during the authorization code-for-token exchange and is never exposed to the browser.

Infrastructure

• Production database: PostgreSQL hosted on Neon with TLS enforced.
• Application hosting: Vercel.
• All public traffic is served over HTTPS.
• Standard security response headers are configured by the application (including X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and a restrictive Permissions-Policy).

Auditing and idempotency

• The database schema includes an audit_logs table for recording sensitive events (for example, OAuth connect, failed token exchanges) and a webhook_events table to guarantee idempotent processing of incoming webhook deliveries once webhooks are enabled.

Access to production

• Access to the production database and hosting platform is restricted to authorized maintainers using individual accounts with strong authentication.
• Customer/seller data is used only to provide the ShopBoost dashboard and integration features described in our Privacy Policy and Terms of Service.

What we do not claim

To be transparent about the current stage of the product, ShopBoost currently does not claim:

• SOC 2 attestation
• ISO/IEC 27001 certification
• PCI DSS certification
• A completed formal third-party penetration test
• A 24/7 security operations center

These items may become part of ShopBoost’s security program in the future. We will update this page only when the corresponding controls are actually in place.

Incident response

ShopBoost follows a lightweight, written incident response process appropriate for an early-stage SaaS. We do not claim a 24/7 security operations center; instead, we commit to handling incidents in a structured, traceable way.

1. Identify and assess. When a potential incident is reported or detected (via logs, alerts, customer report, or third-party disclosure), an authorized maintainer opens an internal incident record and performs an initial triage to confirm whether a real incident exists and to assign a preliminary severity.
2. Contain. Affected systems, sessions, or credentials are isolated as quickly as possible — for example, by revoking compromised authorization tokens, rotating server-side secrets, invalidating user sessions, or temporarily disabling the affected code path.
3. Investigate scope and impact. Logs, audit records (audit_logs), and database state are reviewed to determine what data, which organizations, and which sellers were affected, and over what time window.
4. Remediate. The underlying cause is fixed in code or configuration. A regression test or detection rule is added when applicable.
5. Communicate. When the incident affects users, partners, or the connected sales platform, we notify the affected parties with the information needed to understand impact and any action they may need to take. Regulatory notifications (for example, LGPD) are made when required.
6. Rotate credentials and tokens as needed — including the session signing key, token encryption key, platform app credentials, database credentials, and any impacted seller’s authorization tokens.
7. Document and learn. The incident, its timeline, scope, root cause, and the prevention actions taken are written up in an internal record so the same class of issue is less likely to recur.

Security incidents and vulnerability reports should be sent to shopboost12@gmail.com. Please include enough technical detail for us to reproduce and assess the issue.

Vulnerability management

ShopBoost is an early-stage SaaS. Our vulnerability management process is appropriate for that stage and is described here honestly, without overstating what is in place today.

• Dependency review. We use npm audit and routine package updates to identify known vulnerabilities in third-party libraries. We respond to GitHub and Vercel security alerts when they are available for our repository and deployments.
• Code review. Changes that go to production are reviewed before merge. Sensitive areas — authentication, session handling, the authorization flow, token storage, and webhook handling — receive extra scrutiny.
• Secrets handling. Production secrets (database URLs, session signing key, token encryption key, platform app credentials) are stored as environment variables on the hosting platform and are not committed to Git. The repository’s .env.example ships only with placeholder values.
• Prioritization. Vulnerabilities are prioritized by severity and potential impact on customer data, with critical and high issues addressed with priority over lower-severity findings.
• Up-to-date stack. The Next.js framework, the database driver, and other core dependencies are kept on supported, security-patched versions. We monitor advisories relevant to the stack we ship.
• Honest scope. ShopBoost does not currently claim a completed formal third-party penetration test, SOC 2 attestation, or ISO/IEC 27001 certification. Those items may become part of our security program in the future; if and when they do, this page will be updated to reflect what has actually been completed.

Reporting a security issue

If you believe you have found a security vulnerability in ShopBoost, please contact shopboost12@gmail.com with the technical details. We ask that you do not publicly disclose the issue until we have had a reasonable opportunity to investigate and remediate it according to the incident response process described above.