1995–1998: When the Web Started Acting Like an API Surface

In the mid-1990s, most sites weren’t exposing “developer platforms” in the modern sense. Yet a lot of server functionality was becoming accessible through predictable HTTP requests. If you could craft the right URL, query string, and form body, you could often get a server to return data, trigger an action, or create a record.

That’s the key historical point: early dynamic web programming created repeatable request/response patterns. Even when the response was HTML meant for a human, the interface itself was programmatic enough that developers could automate it. In other words, the web was gradually turning into an integration layer.

As these integrations became valuable, site owners began experimenting with access control patterns. Not all of them were called “API keys,” but many served the same purpose: identify the caller, limit abuse, and separate legitimate automation from unwanted traffic.

CGI and Forms: The Original “Endpoints” and Their Security Assumptions

Common Gateway Interface (CGI) scripts were a major driver of early web dynamism. A typical flow was straightforward:

1. A user loads an HTML page.
2. The user fills out a form.
3. The browser submits data to a CGI script via GET or POST.
4. The script reads parameters, does work (like querying a database or sending an email), then prints HTML.

Functionally, that CGI script is an API endpoint: it takes inputs and returns outputs. But security assumptions were different. Many scripts were written with an implicit belief that calls would come only from the site’s own pages and from real users, not from automated clients. That assumption didn’t hold for long.

As soon as developers realized that a form submission could be replicated by code, “developer access control” became an operational concern. This era produced a grab bag of protection mechanisms—some robust, some fragile, and many surprisingly influential in shaping later API key conventions.

Browser Scripting Enters the Story: JavaScript as a Request Shaper

JavaScript arrived in the mid-1990s and quickly became a way to validate forms, adjust parameters, and create more interactive flows. Even before modern XMLHttpRequest-style patterns became common, browser scripting influenced access control in subtle ways:

• Hidden fields and calculated parameters: Scripts could populate hidden inputs or compute values before submission. Some developers treated these as “proof” the request came from their page.
• Client-side validation: Scripting reduced malformed requests but did not prevent intentional abuse. Still, it shaped expectations around “good” vs. “bad” traffic.
• Obfuscation as a control: Not security in the strict sense, but many early sites relied on the idea that if an integration pattern wasn’t obvious, it wouldn’t be exploited.

This is historically important because it foreshadowed a recurring theme in API security: the tension between client-side signals and server-side trust. By the late 1990s, developers were learning (often the hard way) that anything in the browser could be mimicked.

The Earliest “API Keys”: Shared Secrets in Query Strings and Form Fields

In 1995–1998, many sites implemented access control in the simplest possible way: a shared secret passed with each request. It might have been labeled “password,” “id,” “partner,” or “code.” The exact naming varied, but the behavior resembles a modern API key:

• Static string included on every call: Often a parameter like ?code=PARTNER123 or a hidden form field.
• Server checks the value and allows or denies: A minimal gate, easy to implement in CGI or early server frameworks.
• Key distribution out-of-band: Shared via email or private documentation rather than self-serve dashboards.

These “keys” frequently ended up in server logs, browser history, bookmarks, and referrer headers—an immediate lesson in why placing secrets in URLs is risky. Yet the pattern endured because it was accessible: it required no special client libraries and worked with plain forms, which were the integration primitive of the day.

Access Control Patterns That Filled the Gap (Because API Gateways Didn’t Exist Yet)

Without dedicated API management layers, early developers relied on a mix of operating system controls, web server configuration, and application logic. Several patterns were especially common in 1995–1998:

1) HTTP Basic Authentication and Directory Protection

Many teams used web server access control (for example, directory-level protection) to shield scripts and data. HTTP Basic Auth was simple and widely supported by browsers and command-line tools. While Basic Auth isn’t an “API key,” it served the same role: a straightforward credential sent with each request.

As HTTP evolved, expectations around headers, caching, and request semantics became clearer. For context on this period’s HTTP direction, the HTTP/1.1 specification work (documented in RFCs) helped formalize behavior that later API security designs rely on. A key historical reference is RFC 2068 (HTTP/1.1).

2) IP Allowlisting

If a “partner” system needed automated access, a common approach was simply to allow requests from specific IP addresses. This worked reasonably well for server-to-server calls (where IPs were stable) but was brittle for users on dial-up or changing networks. Still, it was one of the earliest attempts at separating human browsing from machine integration.

3) Cookie-Based Sessions as a Control Boundary

By the late 1990s, cookies were widely used for sessions. Sessions weren’t invented for APIs, but they became an access control boundary: if you had the session cookie, you were “logged in.” That model carried forward into many early “API-like” endpoints that were originally built for web apps.

4) Referrer Checks and User-Agent Filtering

Some sites checked the HTTP Referer header to see whether a request “came from” an internal page, or filtered by User-Agent to block known bots. Historically, these were common because they were easy to add, but they were never reliable security measures. They illustrate an early stage of API thinking: using available request metadata to infer intent.

5) Rate Limits (Manual and Scripted)

Even before formal “rate limiting” products, operators used crude throttles: sleep calls in scripts, per-IP request counters, or scheduled jobs. Abuse wasn’t always malicious; it could come from enthusiastic automation. That pushed teams toward policies that later became standard for API keys: quotas, per-client limits, and monitoring.

Why This Era Matters: It Set the Norms for Developer Access Control

Modern API platforms tend to present API keys as a clean, standardized feature: generate a key, attach it to a request, measure usage, rotate keys, revoke access, and audit behavior. In 1995–1998, the same needs existed, but the tooling and vocabulary did not.

What emerged instead were norms:

• Credentials become part of the request: whether as parameters, headers, or auth dialogs.
• Partners need separation: the idea of identifying “who is calling” became practical, not theoretical.
• Operational control matters: revocation, monitoring, and throttling became visible needs as soon as integrations scaled.
• Client-side tricks are not security: browser scripting and hidden fields could improve UX, but they could not establish trust.

This chapter is also a reminder that “API history” isn’t only about data formats or protocols. It’s equally about control: once you expose a capability over HTTP, you need rules for who can use it and how often.

If you’re building automation today, it’s worth recognizing how long developers have been wrestling with the same themes—authentication, authorization, and abuse prevention—just with different tools. For more practical explorations of automation and modern implementation patterns, you can browse resources at https://automatedhacks.com/.

FAQ: API Keys and Access Control in the 1995–1998 Web

Were API keys commonly used between 1995 and 1998?

Not commonly under the exact name “API key,” but shared-secret patterns were widespread: special query parameters, hidden form fields, and partner codes used to gate access to CGI scripts or data feeds.

What was the biggest weakness of early “API key” patterns?

Secrets were often placed in URLs or forms, making them easy to leak via logs, bookmarks, browser history, and referrers. Rotation and revocation were also difficult because keys were frequently hard-coded into scripts.

How did browser scripting affect early API access control?

JavaScript could shape requests (like adding hidden fields), but it couldn’t establish trust. Attackers and automation could replicate scripted requests, which pushed developers toward stronger server-side checks.

What access control techniques from that era still exist today?

HTTP Basic Auth, cookie-based sessions, IP allowlists, and rate limiting all remain in use. The modern difference is that they’re usually managed with dedicated infrastructure and clearer standards rather than ad-hoc script logic.