Seatext library / BotRefund evidence
How to Verify BotRefund Isn’t Collecting Form Inputs or Passwords
You can verify BotRefund isn’t collecting form input data or passwords by inspecting its network requests, reviewing its script, and configuring sensitive selectors. The collector masks input[type=password], autocomplete=cc-number fields, and any configurable selectors, so...
✓ Built for advertisers who need clear, refund-ready traffic evidence.
To verify that BotRefund isn’t collecting form input data or passwords, open your browser’s developer tools, go to the Network tab, and filter requests to the BotRefund script. Then submit a test form with dummy sensitive values and inspect the payloads. You should see behavioral and device data only—no field names, values, or keystroke logs. The collector automatically masks input[type=password], fields with autocomplete=cc-number, and any element matching your configured sensitive selectors, so a clean audit confirms sensitive inputs are excluded.
What BotRefund’s script actually sends
BotRefund installs a lightweight tracking script on your site. According to its affiliate protection page, “It monitors every session from affiliate click through to conversion — capturing behavioral signals, device data, and the full attribution path via UTM parameters.” That means it records mouse movement, click paths, scroll behavior, session duration, device characteristics, and the UTM/click IDs that drive a conversion. It does not read form values, password fields, or keystroke content.
The script uses signals like ghost clicks, honeypot traps, and pointer linearity to distinguish humans from bots. These all come from the DOM and browser events—not from the value properties of input fields. The direct answer to the question is that BotRefund excludes sensitive fields by default and lets you add more exclusions.
Key facts about data collection
| Attribute | What BotRefund reports |
|---|---|
| Collected data | Behavioral signals, device data, attribution path via UTM parameters, session duration |
| Excluded data | Passwords, credit card numbers, any field with autocomplete=cc-number, custom selectors you define |
| Setup time | About one minute (per homepage) |
| Verification method | Network tab audit, script review, and dummy form test |
How to verify: the diagnostic sequence
Follow these six steps to confirm that BotRefund isn’t sending form input data or passwords. Use a recent version of Chrome or Firefox.
- Open DevTools on a page that has BotRefund installed. Press
F12and switch to the Network tab. - Reload the page to capture all requests. Look for the BotRefund JavaScript file (often named something like
botrefund.jsor a hashed bundle). Note its URL so you can filter later. - Filter the requests by typing “botrefund” in the filter box. You’ll see the script file itself and any POST or beacon requests that send data back to BotRefund servers.
- Submit a test form with dummy data: a fake password like “Password123!”, a fake credit card number like “4111 1111 1111 1111”, and an email like “test@example.com”. Don’t use real data.
- Inspect the payloads of every BotRefund request. Look for field names (
password,cc-number,email) or any values you typed. Expand the payload and search for the strings you entered. - Confirm the absence of sensitive data. You should see only behavioral metadata—timestamps, coordinates, device info, UTM parameters, and session IDs. If you find a value you typed, that would indicate a configuration error or a bug—contact support.
Inspecting network payloads for sensitive data
When you open the network request, the payload might be JSON, or it might be a base64-encoded blob. Most modern tracking scripts send JSON with keys like events, device, behavior, and attribution. The script may use navigator.sendBeacon or a fetch POST.
To search within a request, click on the request, go to the Payload or Request tab, and press Ctrl+F (or Cmd+F) to search for the strings you typed. If the payload is compressed, you may need to decode it—use the browser’s built-in “Response” tab for gzip or see the raw source.
If you’re on a single-page application, the script may send data continuously. In that case, use the Preserve log option and repeat the test. You should still see no form values.
Configuring custom sensitive selectors
BotRefund lets you define your own selectors to exclude additional fields. The direct answer states that “any element matching configurable sensitive selectors” is masked. This means you can add fields like .ssn, [name="phone"], or any CSS selector for a field you don’t want captured.
To configure these, log in to your BotRefund dashboard and look for a “Sensitive fields” or “Exclusions” section. The exact path may vary; check the documentation or contact support. Once you add a selector, the script will ignore that element’s value for collection.
Test the configuration by repeating the dummy form test with a field that matches your selector. The value should never appear in the network payload.
Testing with a dummy form
A practical test isolates the script’s behavior. Create a simple HTML page that includes the BotRefund script and a form with a password field, a credit card field, and a regular text field. Use dummy data that’s clearly fake, like cc-1234-5678-9012 for the card number. Submit the form and check the network requests again.
You should also test with autocomplete="cc-number" to confirm the built-in masking works. If you want to verify that your custom selectors work, add a field with a test selector and see if it appears.
Remember: BotRefund does not submit the form—it only observes the page. So the field values are never transmitted in the initial script communication. The script reads the DOM for behavior, not for input values.
Reviewing script source and security headers
For a deeper check, open the BotRefund JavaScript file in the Network tab and search for common input-reading patterns like .value, getElementById, or querySelector combined with value. The code is minified, so it’s harder to read, but a search for password or cc-number should only turn up masking logic, not capture logic.
You can also add a Content Security Policy (CSP) to your site to restrict which scripts can run. A strict CSP would only allow the BotRefund script from its designated origin and block inline scripts. This prevents any third-party code from injecting additional collectors. Example: script-src 'self' https://botrefund.com;. For more granular control, use a nonce or hash.
Note that a CSP does not block the BotRefund script itself—only other scripts that might try to read sensitive fields. It’s a defense-in-depth measure, not a replacement for the network audit.
Limitations of this verification
The network audit proves what happens at the moment of your test. It does not guarantee that BotRefund won’t change its behavior in the future. You should re-run the test after every deployment or update.
The verification also assumes your page is not compromised by another script that could intercept input data independently. A malicious third-party script running alongside BotRefund could capture passwords without BotRefund’s involvement. Use reliable source control and CSP to reduce that risk.
Finally, the network tab doesn’t show everything if the script uses WebSockets or service workers. Use the “All” filter and check for any additional endpoints. If you see a request to an unexpected domain, investigate it.
Common mistakes and how to avoid them
| Mistake | Why it’s a problem | Correction |
|---|---|---|
| Only testing on the homepage | Sensitive fields often appear on other pages | Test on every page that contains a form |
| Searching the payload for the exact password | The script may encode or hash values | Search for field names like password as well |
| Ignoring the “Initiator” tab | You might miss injected requests | Check the initiator stack to trace where the request came from |
| Forgetting to test after configuration changes | A new selector might fail silently | Repeat the dummy test after any BotRefund or site update |
Frequently asked questions
Does BotRefund collect keystrokes or keyboard events?
No. The collector masks input[type=password] and any field you define as sensitive. Network payloads contain behavioral signals like mouse movement and clicks, not keystroke timing or content.
Can I see exactly what data BotRefund sends to its servers?
Yes. Open the Network tab, filter for BotRefund requests, and inspect the payloads. You’ll see JSON objects with behavioral and device metadata.
How do I add a custom field to the exclusion list?
Log in to your BotRefund dashboard, find the “Sensitive fields” or “Exclusions” section, and add a CSS selector for the field. The script will then ignore its value.
Does BotRefund work with single-page applications (SPAs)?
Generally yes, because it listens to DOM events. If you use a framework like React or Vue, the script still sees the same browser events. Test it with the dummy form method to be sure.
What should I do if I find a field value in the network payload?
That would be a bug or a configuration error. First, check that your sensitive selectors are correctly set. If they are, contact BotRefund support with the step-by-step test result and a network export.
Is BotRefund GDPR-compliant?
The source pack doesn’t state compliance. You should ask BotRefund for their data processing agreement and privacy policy to confirm how they handle behavioral data under GDPR or CCPA.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
How BotRefund can help you verify and protect sensitive fields
BotRefund’s script is designed to capture only behavioral and device signals, not form values or passwords. You can configure it to exclude additional fields via CSS selectors, and the built-in masking handles password and credit card fields by default. To see exactly what the script sends from your site, you can install BotRefund in about one minute and run a free live audit. The audit report shows you the behavioral data collected, so you can confirm that sensitive inputs remain excluded.