CGI shopping cart scripts: how server-side e-commerce worked and when it still applies

How session state worked in CGI carts

A persistent process like a database or application server holds state in memory between requests. CGI scripts do not: each request forks a new process, runs the script, and exits. Cart state had to live somewhere between requests. The two common approaches were cookies (storing the cart contents or a session token in the browser) and server-side session files (storing cart data in a temp file named by a unique session ID, with the ID passed in a cookie or hidden form field).

Killercart, the CGI shopping cart product sold on this domain in the late 1990s, used a server-side session file approach. Each visitor got a session ID in a cookie; the script read the session file, updated it, and wrote it back on every cart interaction. The product catalog was typically a flat tab-delimited file the script read on each request. No SQL database was required, which was an advantage on shared hosting environments of the era where MySQL was not always available.

Security concerns specific to CGI carts

Storing prices in hidden form fields and trusting them on the order submission page was a common early mistake. An attacker could edit the form before submitting, change the price of every item to zero, and generate a zero-dollar order. The fix is to store prices server-side and look them up by product ID on order submission, never accepting a price the browser sends as authoritative.

Session file management also needs care: session files must be stored outside the web root, session IDs must be long and random enough that they cannot be guessed, and old session files must be cleaned up to prevent disk space exhaustion. PHP solved many of these problems by building session handling into the language runtime; CGI scripts have to implement each safeguard explicitly.

When a custom CGI cart still makes sense

For most new e-commerce projects, a dedicated platform (WooCommerce, Shopify, Stripe Checkout) is the right answer. They handle payment card security, PCI-DSS compliance, tax calculation, inventory, and fulfillment integration. Building a custom CGI cart means owning all of that yourself.

There are narrow cases where a minimal CGI order script is still appropriate: a simple request form that does not process payment directly (sends an order inquiry for manual invoicing), an internal tool where PCI scope is not a concern, or a site that already has a CGI stack for other reasons and needs a lightweight add-to-cart for a small product catalog. In all of these cases, the CGI script is a form handler that emails an order summary rather than a true payment processor.