Online store security checklist

• Prices, discounts, shipping, tax and totals are computed server-side from the database at checkout; client-supplied amounts, SKUs' prices and discount values are ignored; order totals carry a CHECK constraint.

• Customers can only read their own orders and carts (RLS plus ownership checks; guest orders need a signed, expiring lookup token); admin routes require the merchant role; order IDs are non-guessable UUIDs and the human number alone never grants access.

• Customer email, phone and addresses are personal data: collected minimally, excluded from logs, access-controlled, exportable and erasable on request (order totals retained for tax law with PII anonymised).

• Merchant images are validated by size, MIME and magic bytes, re-encoded server-side (stripping EXIF/active content) and served from the media origin, never the app origin; CSV imports are size/row capped and parsed without formula execution.

• GDPR / ePrivacy (applies to EU customers): Cookie consent for non-essential analytics and marketing, export and erase for customers, DPA with processors, retention of orders as legal records with PII minimised.
• Consumer law (applies to EU/UK consumers): Clear returns and refund policy, delivery estimates, price display rules, 14-day withdrawal rights and order confirmation emails.
• CAN-SPAM / marketing consent (applies to marketing emails): Abandoned-cart and marketing emails need consent, unsubscribe links and a physical address.
• Accessibility: WCAG 2.2 AA: alt text on product media, keyboard-operable variant picker and checkout, visible focus, form error messaging.

• image storage gb: hard cap on product-media bytes; presigned uploads refused at 100%.
• image processing jobs per day: daily cap on rendition jobs; over the cap uploads are refused, not queued.
• cdn egress gb month: plan ceiling with alert at 80%; hotlink and bot traffic challenged at the edge.
• emails per day: capped by EMAIL_DAILY_CAP; order confirmations are reserved first, marketing and cart recovery are dropped first.
• tax api calls per day: tax quotes cached per (cart hash, address) and capped per day; over the cap falls back to the flat configured rate.

Forge64 gives every app its own Postgres database and runs a quality gate that flags unauthenticated writes and secrets in client code before you see the app. It does not replace your own testing, and it holds no third-party security certification today.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

• Sign in as two different users and try to open each other's records by changing the id in the address.
• Submit each form with an empty value, a very long value and a script tag, and check the result.
• Call each write endpoint without signing in and check that it refuses.

What is the biggest security risk in an online store?

Prices, discounts, shipping, tax and totals are computed server-side from the database at checkout; client-supplied amounts, SKUs' prices and discount values are ignored; order totals carry a CHECK constraint.

Does an online store have compliance obligations?

GDPR / ePrivacy, if you have EU customers: Cookie consent for non-essential analytics and marketing, export and erase for customers, DPA with processors, retention of orders as legal records with PII minimised. This is a starting point, not legal advice.

Will Forge64 certify my app as secure?

No. Forge64 holds no third-party security certification today and does not certify apps. The checklist is a way to test your own app.

• How to build an online store
• Online store architecture
• Example prompt for an online store
• Online store scaling checklist
• Often combined: SaaS dashboard
• Often combined: marketplace
• All app types