Security is a core part of how StoreFlux is built, not an add-on. This page summarises the mechanisms that protect the platform and sets out how researchers can report problems to us. For the marketing overview see the security section of our homepage.
01How we protect the platform
| Area | What we do |
|---|---|
| Tenant isolation | PostgreSQL row-level security enforces tenant boundaries at the database layer, in addition to application-level checks, so a query for one store cannot return another store’s rows. |
| Secrets | Payment-gateway keys and integration OAuth tokens are encrypted at rest with a dedicated secret protector and are never stored or logged as plain text. |
| Payments | Card data is tokenised client-side by Stripe Elements or the PayPal SDK and never touches StoreFlux servers. Payment and refund operations use distributed locks and gateway idempotency keys to prevent double charges or double refunds. |
| Authentication | PBKDF2-SHA256 with 350,000 iterations, 15-minute access tokens, rotating refresh tokens with replay detection, HTTP-only Secure SameSite=Strict refresh cookies, role-based access control and account lockout after repeated failed sign-ins. |
| Transport | All traffic is served over HTTPS/TLS. |
| Auditability | Every administrative action is recorded (who, what changed, before and after, IP address, time) in a queryable audit log. |
| Infrastructure | Containerised services on AWS with managed database, cache and storage, health checks and backups. |
| Access control | Least-privilege database roles; platform administration is separated from tenant access. |
02Reporting a vulnerability
If you believe you have found a security vulnerability in StoreFlux, please tell us privately so we can fix it before it can be misused. Email admin.storeflux@gmail.com with the subject “Security report”. Please include:
- a description of the issue and its potential impact;
- the affected URL, endpoint or component;
- clear steps to reproduce, with proof-of-concept code or requests if possible;
- your contact details and how you would like to be credited, if at all.
Our machine-readable contact details are published at /.well-known/security.txt.
03What to expect from us
- We acknowledge reports within 3 business days.
- We investigate, keep you updated and aim to resolve confirmed issues promptly, with priority given to severity.
- We will let you know when the issue is fixed and, with your permission, credit you for the finding.
04Safe harbor
We will not pursue or support legal action against researchers who act in good faith and follow these guidelines. Please:
- test only against your own stores, or against the public demo store and demo data, never against other customers’ stores;
- do not access, modify, exfiltrate or retain data that is not yours; if you encounter personal data, stop and report it;
- do not run denial-of-service, spam, social-engineering or physical attacks;
- give us a reasonable time to fix the issue before disclosing it publicly.
05Out of scope
- Findings from automated scanners without a demonstrated impact.
- Missing security headers or cookie flags without a practical exploit.
- Rate-limiting or brute-force reports on endpoints that are already limited.
- Vulnerabilities in third-party services (report these to the vendor), and social engineering of staff or customers.
06Incident response
If we confirm a security incident that affects customer data, we will notify affected merchants without undue delay and in line with our Data Processing Addendum (within 72 hours of becoming aware for personal-data breaches), with the information needed to assess the impact.