Rising bot traffic is not only a question of volume and cost. A large and growing share of it is harmful, and much of that harmful traffic exists to find and exploit vulnerabilities in your data infrastructure.
In a recent article, we looked at what rising bot traffic means for your data portal in terms of measurement and infrastructure load. This piece looks at the security side of the same trend: what automated attackers are actually doing, how fast they move, and what portal owners can do to reduce their exposure to the risks they pose.
Automated web is now mostly non-human, and a lot of it is hostile
Automated traffic has overtaken people as the main source of online traffic. According to Imperva’s 2026 Bad Bot Report, bots accounted for more than 53% of all web traffic in 2025, up from 51% the year before, while human activity fell to 47%.
Not all of that automation is friendly. Imperva classifies around 40% of all web traffic as malicious bot activity, and this 2026 analysis reports that AI-driven bot attacks rose roughly 12.5 times in a single year. The same research found that 27% of bot attacks now target APIs directly, bypassing the user interface entirely.
For a public data portal, this means a meaningful slice of the requests hitting your server every day are not readers or researchers. They are automated systems, and some of them are looking for a way in.
From scanning to breach: what malicious bots actually do
Most bot-driven attacks fall into a recognised set of patterns. Open Worldwide Application Security Project (OWASP) – a global nonprofit that provides free, open-source resources, tools, and standards to help make software and web applications more secure – maintains a catalogue of these under Automated Threats to Web Applications. This describes the common ways bots and scripts are used to abuse a site at scale. The ones most relevant to a data portal are summarised below.
| Automated threat | What the bot does | Why it matters for a portal |
|---|---|---|
| Vulnerability scanning | Probes pages, forms, and endpoints for known weaknesses | Finds unpatched software before you do |
| Credential stuffing and brute force | Tries stolen or guessed logins against admin and account pages | Can lead to account takeover and privileged access |
| API abuse and scraping | Hits data and catalogue APIs at high frequency | Drives load, and can expose data or business logic |
| Content and data scraping | Copies datasets and pages in bulk | Consumes bandwidth and removes control over consumption |
| Denial of service | Floods the site with requests | Makes the portal slow or unavailable to human users |
The window to respond to malicious bots has narrowed sharply. Verizon’s 2026 Data Breach Investigations Report found that exploiting vulnerabilities has become one of the most common ways attackers first get into a network and that the average time from a vulnerability being disclosed to being actively exploited has fallen to roughly 10 hours. In practice, automated scanners begin testing a newly published vulnerability within the same day it appears and often much sooner.
For public portals, the threat is not theoretical. In May 2026, the Drupal Security Team disclosed a highly critical SQL injection flaw in Drupal core, SA-CORE-2026-004, and updated the advisory to confirm that malicious bots were trying to exploit it. Sites on a supported version that patched promptly were protected, while sites left on unpatched or end-of-life versions were open to potential attacks. The take home lesson for portal owners is that the safety margin now sits in how quickly you patch a vulnerability, not in whether a flaw affects you.
Why data portals and public-sector sites are exposed
Open data, research, and government portals carry a specific risk profile, for three reasons.
First, they are public by design. Being discoverable is usually the point, so the front door is open to everyone, including automated scanners.
Second, they expose rich APIs. A data catalogue is built to be queried programmatically, which is a strength for legitimate users and a large attack surface for everyone else. Given that APIs are now the leading bot attack target, this issue matters.
Third, they run on widely used software. Portals are commonly built on platforms such as CKAN, Drupal, and WordPress, and popular software attracts mass, automated scanning the moment a new flaw is published.
What can you do to counter these threats?
The single largest avoidable risk here is running unsupported versions. Drupal, for example, provides no security coverage for end-of-life branches, as noted in SA-CORE-2026-004, which means a known flaw can remain open indefinitely. If you are approaching a version deadline, our guide on planning a Drupal upgrade in 2026 walks through the options.
Integrity is part of the same picture. As we discussed in this article in February, recent CKAN work has added protections at the data layer. The just released CKAN version 2.12 introduces file-level hashing so a portal can detect whether a file has been tampered with or duplicated, which supports cleaner security audits.
The earlier article on our site referred to above covered load-related steps such as caching, a CDN (content delivery network), and robots.txt. The list below focuses on the security side, and each item is within reach for a small team.
- Run supported, patched software: Keep your content management system core, extensions, and dependencies current, and treat a critical advisory as a same-week task rather than a monthly one, given how fast disclosed flaws are exploited.
- Put a web application firewall (WAF) in front of the portal: A WAF gives you enforceable rules that bots cannot ignore. It can be tuned against the OWASP automated threat categories.
- Protect authenticated endpoints: Rate-limit and monitor login and admin pages, enable multi-factor authentication where possible, and watch for credential stuffing patterns.
- Secure and rate-limit your APIs: APIs are the top attack surface, so apply authentication, quotas, and per-client limits to catalogue and data endpoints.
- Monitor your logs for scanning: Be alert for unusual spikes to admin, login, and API paths, which are often the first sign of an automated probe.
- Reduce what is exposed: Remove or lock down staging, test, and unused endpoints so there is less for a scanner to find.
For a step-by-step starting point, our free Bot Traffic Readiness Checklist is a one-page guide you can work through.
How Link Digital can help
If you would rather not manage these tasks in-house, that is what our managed hosting service is for. We handle patching, WAF configuration, rate limiting, monitoring, and bot management, and keep you informed on how your portal traffic is trending, so your team can stay focused on your data and your users.
If you would like a review of what bot traffic and exposure currently look like on your portal, contact us and we can look at your logs and talk you through it.
Frequently asked questions
Is bot traffic a security threat or just an analytics and cost problem? It is both. Rising bot traffic distorts analytics and increases infrastructure load, and a large share of it, around 40%, is also actively malicious.
What kinds of attacks do malicious bots run against data portals? The most common are vulnerability scanning, credential stuffing and brute-force login attempts, API abuse and scraping, bulk data scraping, and denial-of-service floods. OWASP catalogues these under Automated Threats to Web Applications.
How quickly are newly disclosed vulnerabilities exploited? Very quickly. One report cited the average time from disclosure to active exploitation at around 10 hours, and automated scanners often begin testing a new flaw the same day it is published.
How do we reduce exposure without blocking legitimate crawlers and AI agents? You should focus on security hygiene rather than blanket blocking. This means ensuring supported and patched software, placing a WAF in front of the portal, protecting and rate-limiting login pages and APIs, and monitoring logs for scanning. This keeps the portal discoverable while closing the gaps attackers look for.
Sources
- Imperva, 2026 Bad Bot Report: Bots in the Agentic Age (bot share of web traffic, API attack share)
- Imperva / Thales, press release on the 2026 Bad Bot Report (malicious bot share, growth in AI-driven attacks)
- OWASP, Automated Threats to Web Applications (taxonomy of bot-driven attacks)
- Verizon, 2026 Data Breach Investigations Report, as reported by ZeroFox (time from disclosure to exploitation)
- Drupal Security Team, SA-CORE-2026-004 (highly critical SQL injection, in-the-wild exploitation, end-of-life coverage)
