Kitesurf: who may control the company browser?
An automated browser needs an owner for who may control it. Assess operator access, action destinations and access removal before approving its use.
Leggi in portogheseBy Pentesty
The announcement creates an operating decision
On November 13, 2026, Cloudflare released Kitesurf under Apache 2.0. The experimental engine uses Workers and CDP clients. Available code does not establish the security of an enterprise deployment.
The official README warns that the engine has no authentication of its own and its workers.dev address is public by default. Someone reaching the instance can control it and consume account resources. That description informs acceptance scope; it does not establish exposure at a particular company.
Identify the operator before connecting the agent
Begin with a written decision about who may control the instance: maintenance staff, an approved application or both. Associate each client with an owner and a purpose. Authorization to administer the browser should be reviewable without having to discover which person shared a credential during installation or subsequent maintenance.
Treat the automation client as an access path in its own right. A person may enter through an interface while a service opens a different connection; approving only the first experience leaves the second unresolved. The design should identify the entry points and who can provide authorization evidence for each one.
Arrange protection before making the route reachable
In an authorized assessment environment, list the addresses the deployment intends to expose, including those used for version testing. The infrastructure handover should identify where the access decision will be applied. An address should not be accepted as protected simply because another address in the same project requires a login.
Make publication a joint task for operations and identity administrators. The route owner presents the intended configuration; the access administrator confirms policy and the revocation path. If there is an interval when entry would remain open, resolve it before acceptance while keeping the record of what the team actually checked.
Observe the connection and the action outcome
Prepare three scenarios using a laboratory website: an unauthorized client, an allowed client and a client whose access has just been removed. Establish the expected result before execution. Keep the time, identity, requested route and evidence showing whether the connection was accepted or refused under the evaluated configuration.
The allowed client should perform a small task, such as opening a synthetic page and producing an identifiable result. Check destinations outside the agreed scope as well. The analysis of agent network egress boundaries develops the complementary question: browser entry should not replace a decision about which resources its operator may reach.
End access and retain what was demonstrated
Include an established session in the access removal procedure. Removing a person from a directory and ending control they already exercise are different observations. The team should demonstrate the behavior it can verify, state the remaining limitation and identify who authorizes additional action if the session is still usable.
Before changing the engine or client version, repeat the scenarios supporting acceptance. Retain the evaluated configuration and previous results for comparison. The discussion of opening and building repositories extends the review of acquired code. Final approval should identify the version, authorized operators and outstanding issues rather than relying on a successful installation alone.
Frequently asked questions
Does open source mean secure access by default?
Available code permits inspection and modification but does not establish the environment’s configuration. The team needs to demonstrate the access decision applied to the entry points it intends to expose.
Does a login screen complete the assessment?
No. Include the automation client, intended routes and termination of an established connection. The report should state which paths were actually observed and which remain without sufficient evidence for an acceptance decision.
Must the assessment use third-party websites?
Use a laboratory website and synthetic data within the received authorization. Choose a small task with an observable result that does not involve real customer accounts, documents or transactions.
What belongs in the acceptance record?
Identify the version, routes, allowed operators, completed scenarios and outstanding issues. Assign review after changes and retain an access removal procedure that operations can demonstrate with the evidence available.
Sources and references
Original Pentesty analysis, published November 13, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.