Security Overview

1. Data in Transit

All traffic is served over HTTPS. HTTP requests are redirected and HTTP Strict Transport Security is sent, so browsers refuse to downgrade after the first visit. Session cookies are marked Secure, so they are never transmitted over an unencrypted connection.

2. Authentication & Sessions

• Passwords are stored as salted adaptive hashes. They are never stored in plain text or any reversible form, and cannot be recovered by us — only reset.
• Session identifiers are regenerated at every sign-in, defeating session fixation.
• Session cookies are HttpOnly (unreadable by JavaScript), Secure, and SameSite=Lax.
• Repeated failed sign-ins from the same address are throttled.
• Password reset links use 256 bits of cryptographic randomness, expire in one hour, and are single-use.
• Two-factor authentication is available for accounts that enable it.

3. Tenant Isolation

Every database query is constrained by organisation, and by user where the organisation is configured for isolated mode. Record identifiers supplied by a browser are always re-checked against the requesting account before the record is read or written, so guessing another customer's identifier returns nothing.

This is enforced in a single shared code path rather than repeated per endpoint, which is what makes it auditable.

4. Application Security

• SQL injection. All database access uses parameterised statements. No user input is concatenated into a query.
• Cross-site scripting. Values are escaped at the point of rendering, and inputs such as colour codes are validated against a strict pattern on the server.
• Cross-site request forgery. Every state-changing request requires a per-session token verified with a constant-time comparison.
• Content Security Policy restricts which origins may supply scripts and receive connections, together with X-Frame-Options, X-Content-Type-Options and a referrer policy.
• Webhooks. Every inbound webhook — Stripe, Shopify, WooCommerce — is verified by HMAC signature using a constant-time comparison before it is acted upon.

5. Payment Data

Card details are entered directly into Stripe's hosted checkout and never reach our servers. Fopsis does not receive, process or store card numbers, and is therefore out of scope for the storage requirements of PCI DSS. We retain only a Stripe customer reference and subscription status.

6. Infrastructure & Credentials

The application and database are hosted by Hostinger in the United States. Credentials are held in server environment configuration outside the web root and are never committed to source control or exposed to the browser. Administrative access is limited to personnel who require it.

7. Backups & Recovery

The whole database is backed up every night as one consistent snapshot. Before a backup counts, it is checked: it must decompress, be complete, and contain every table. A failed or incomplete backup is recorded and shown on our health checks rather than passing silently. Daily copies are kept for 14 days and weekly copies for 8 weeks, stored outside the website’s public folder and readable only by our hosting account.

Recovery Point Objective: 24 hours. Recovery Time Objective: 24 hours. See the SLA.

8. Monitoring

Automated checks run every 15 minutes covering the application, database, schema state, backup freshness, integration sync age and disk headroom. Failures alert us by email on the transition into failure and again on recovery. Current status is published at status.php.

9. Security Review

The codebase has undergone a structured internal security review covering authentication, authorisation and tenant isolation, injection and scripting, secrets handling, webhook verification, and billing logic. Findings were remediated and re-tested. The forecasting mathematics has separately been validated against independent reference implementations.

10. What We Do Not Yet Have

Stated plainly so you can make an informed decision:

• No SOC 2 or ISO 27001 certification. We have not been audited by an independent assessor. If your procurement process requires a current attestation report, we do not meet that bar today.
• No third-party penetration test. Security review to date has been internal.
• Single-region hosting. There is no hot standby in a second region; recovery from a total host failure is a restore from backup within the RTO, not an automatic failover.
• No customer-managed encryption keys and no bring-your-own-key support.
• No SSO or SCIM. Access is via email and password with optional two-factor authentication.
• No formal bug bounty programme, though we welcome reports (below).
• No off-site backup copy yet. Backups are kept on our hosting provider’s infrastructure, separate from the website, but not yet copied to a second provider.
• No scheduled restore drills yet. Backups are checked for completeness when they are taken; they are not yet restored into a test database on a schedule.

These are on our roadmap in the order that customer demand dictates. We would rather tell you now than during a security review.

11. Reporting a Vulnerability

Email support@forecastproai.com with the subject “Security”. Please include enough detail to reproduce the issue. We will acknowledge within two business days and keep you informed until it is resolved.

We will not pursue legal action against researchers who report in good faith, avoid privacy violations and service degradation, and give us reasonable time to remediate before public disclosure.