Browser Automation and Web Login

Browser automation is one of the more recognizable Flocks capabilities, and also one that is easy to misuse. The core idea is that when a system has no API, or API coverage is insufficient, Rex can open a web page, log in, click, and extract data like an analyst.

Browser automation is not a universal replacement. This guide highlights the optimal use cases for browser automation, as well as scenarios where API or log-based integrations should be prioritized instead.

Scenario Overview

Enterprise environments frequently include the following systems:

• A Web console exists, but no public API
• An API exists, but only covers basic functions; key data still requires logging into the backend
• Legacy systems where API documentation has been lost
• External third-party platforms that only allow interactive login

For these systems, the traditional process often relies on screenshots, copy-paste, or periodic Excel exports. Flocks browser tools can automate this interaction layer, but it is always a fallback path, not the preferred path.

Best-fit Task Forms

Scenario	Example
Web-only data collection	A cloud security console only provides Web and has no API
One-off investigation	Quickly inspect data on a page in a platform
Session persistence (Manual login once, automated execution thereafter)	After a manual QR-code / password login, Rex continues all subsequent operations in this session
Discover backend interfaces	Let Rex run through the browser, observe XHR requests, then turn those requests into stable API tools

The last item is the key to this scenario: Flocks promotes a closed loop of "browser breakthrough -> tool capture." The browser is the way into the system, not the final state.

Scenarios Where It Should Not Be Used

For the following scenarios, return to the API / log path. See Internal Security Product Integration:

Scenario	Reason
The device provides a mature API	Browser approach is less stable than API
The task must run daily on schedule over the long term	Page structure, login state, and anti-bot rules all change, making maintenance costly
Deployment is on a remote / GUI-less cloud host	No convenient human-machine interaction environment for login
Large data volume or high frequency	Browser rendering is page-by-page and has much lower throughput than API
Compliance-sensitive and audit trail required	API call records are easier to audit than browser behavior

Local Installation vs Docker

The Flocks deployment method directly determines whether browser scenarios are usable:

Deployment method	Headed interactive login	Headless background run	Recommended scenario
Local installation	Supported	Supported	Scenarios requiring manual login, QR code, or SMS verification
Docker deployment	Not suitable	Supported	Pure background running, API pulls, headless automation
Remote cloud host	Not suitable	Supported	Scheduled tasks, batch processing

If a human needs to complete QR-code, SMS verification, or password login before Flocks continues operating, prefer local installation.

For the comparison between local installation and Docker, see Installation Method Notes in Quick Start.

Steps (WebUI)

Step 1: Create a Session and Describe the Goal + Interaction Method

"Open https://cloud-security-console.example.com. After I finish logging in, go to the 'Alerts' page and collect all alerts from the last 24 hours."

Rex recognizes this as a browser task that requires human intervention:

• Open browser -> navigate to the target URL
• Pause at the login page to request manual user intervention.
• User completes QR-code / password / verification code
• Rex takes back control and continues the remaining actions

Step 2: Observe How Rex Collects Data

Rex proceeds step by step:

1. Find the "Alerts" entry by reading page structure / aria labels / text
2. Apply time filter = "last 24 hours"
3. Page through / scroll / export
4. Extract structured data

In local deployment, users can see the live browser view in the WebUI sidebar.

Step 3: Check Whether Rex Finds a Backend Interface That Can Be Captured

In complex scenarios, the page is often an SPA and data comes from XHR. Rex can:

• Read the XHR / Fetch list in the Network panel
• Identify which interface is the real data source
• Extract request method, URL, Headers, Body
• Turn the interface into an API tool so future runs no longer use the browser

This is the "browser breakthrough -> tool capture" loop described earlier. Once captured, future tasks can directly use the API tool, improving stability and efficiency.

Step 4: Login State Management

Login state, such as Cookie / Session / Token, remains for a period of time with the session. Typical strategies:

Strategy	Suitable scenario
Manual login every time	Highly sensitive scenarios where persistent credentials should not be retained
Reuse login state for a while	Several related tasks need to be completed during the same day
Let Rex capture Cookie into a tool	Explicitly authorized long-term automation; Cookie expiration requires manual login again

Real Case Walkthrough: Methodology

Browser scenarios often appear together with other scenarios:

• Alert triage, see alert-triage: when TDP / NDR has no API, Rex logs into the page and fetches alerts
• Host inspection: if some cloud vendor consoles do not expose SSH and only provide a Web terminal, Rex can operate the Web terminal for read-only inspection
• Threat intelligence, see threat-intel: when an intelligence platform web page has tags / associations not available in the API, browser automation can enrich data
• Asset discovery, see asset-discovery: some asset platforms only provide Web, and the browser can be used directly

A Practical Decision Standard

When asked whether a system can be integrated, judge in this order:

1. Is there an API? If yes, use Internal Security Product Integration
2. Is there log push / message queue / scheduled export? If yes, fetch from the aggregation layer
3. Can API documentation be obtained? If yes, prioritize API integration
4. If none of the above applies, then consider the browser approach

Choosing the browser approach first is the most common misuse of this capability.

Prerequisites

Dependency	Requirement
Deployment method	Manual login requires local installation; pure background work can also use Docker
Browser tool	Browser MCP / browser tool is enabled
Login capability	The user can complete one manual login on the deployment node or its forwarded display layer
Stable network	Browsers are sensitive to network fluctuation; remote hosts are not recommended

Boundaries and FAQ

Question	Handling
How to complete interactive login in Docker deployment	Use local deployment, or log in locally first and export Cookie within the authorized scope, then import it into the Docker environment
Rex stays on the login page	Usually caused by CAPTCHA or risk control; manual login is required
Page structure changes and the flow no longer runs	Update selectors in the Skill, or let Rex explore the page again
Multiple sessions conflict in the same browser	Use separate browser contexts / profiles for different tasks
Strict anti-bot rules	Do not forcibly bypass them; consider slowing down, switching to API, or abandoning automation
Large data volume makes execution slow	Browser throughput is low; for scale, capture backend XHR and turn it into an API tool
Production requires audit trail	Require Rex to write an operation log for every step in the Skill and persist logs

When to Upgrade from "Browser Approach" to "API Tool"

Once a browser task:

• Has been scheduled, such as daily / hourly runs
• Has run stably for a period of time
• Has clear and stable backend interfaces

Rex should be asked to refactor it into an API tool:

"Extract the backend interfaces actually called in this browser flow and generate an independent API tool, so future runs do not use the browser."

This is key to keeping Flocks solutions stable over time. The browser should be an integration bridge, not the final form.

---

Related Resources: Scenario Overview · Internal Security Product Integration · Threat Intelligence and IOC Triage · Internet Asset Discovery · Installation Method Notes