How Safari Prevents WebDriver Session Hijacking

This article explains the security mechanisms built into Apple's Safari web browser to prevent unauthorized automated scripts from hijacking an active user's browsing session. By requiring explicit administrator opt-in, enforcing strict session isolation, displaying unmistakable visual indicators, and utilizing immediate user-interruption protocols, Safari ensures that WebDriver execution remains completely separate from personal browsing data and under the user's ultimate control.

Explicit Administrator Opt-In

Safari disables WebDriver automation by default. A script cannot silently initiate a session in the background without prior authorization from the machine's owner. To allow WebDriver to run, a user must manually reveal the hidden "Develop" menu in Safari's settings and check the "Allow Remote Automation" option. Alternatively, a user must run the safaridriver --enable command in the macOS Terminal, which requires administrator privileges and a system password. Without this explicit opt-in, all WebDriver requests are outright rejected.

Strict Session Isolation

The most critical defense against session hijacking is Safari's inability to attach WebDriver to an existing, normal browsing window. When safaridriver initiates a session, Safari creates a completely separate, ephemeral browsing profile—similar to a Private Browsing window.

This isolated session has no access to the user's active cookies, saved passwords, browsing history, LocalStorage, or installed extensions. When the automated test concludes and the session is terminated, Safari permanently deletes all data associated with that temporary profile. Consequently, a malicious script cannot use WebDriver to steal active login tokens or manipulate a tab the user currently has open.

Unmistakable Visual Indicators

To prevent a script from tricking a user into entering sensitive information into an automated window (a form of reverse-hijacking or phishing), Safari alters the browser's user interface during WebDriver execution. The Smart Search Field (address bar) of an automated Safari window turns bright orange. This distinct visual cue ensures the user can instantly differentiate between their standard, secure browsing windows and the window controlled by an automated script.

The Glass Pane and Interruption Protocol

Safari strictly prohibits simultaneous interaction between a human user and an automated script. During a WebDriver session, Safari places an invisible "glass pane" over the automated viewport.

If a user attempts to click, type, or otherwise interact with the automated window, the glass pane intercepts the input and immediately pauses the WebDriver script's execution. Safari then presents a system dialog asking the user how to proceed, offering three choices:

• Turn Off All Automation: Terminates the current session and disables the "Allow Remote Automation" setting entirely.
• Stop Session: Terminates the current WebDriver session, returning control of the window to the user (though it remains isolated from their main profile).
• Continue Session: Dismisses the prompt and hands control back to the automated script.

Because the script is frozen the millisecond physical user input is detected, an automated process cannot hijack actions the user is actively taking.

Localhost Restrictions and Concurrency Limits

By default, the safaridriver executable only accepts connections originating from the local machine (localhost). It rejects incoming network requests from external IP addresses, preventing remote attackers from triggering automation sessions over a network. Furthermore, Safari only permits one active WebDriver session at a time, preventing rogue scripts from spawning hidden background sessions while a legitimate test is running.