Drupal feeds

Security public service announcements: Upcoming highly critical release on May 20, 2026 - PSA-2026-05-18

Drupal Planet -

Date: 2026-May-18Description: 

There will be a Drupal core security release for all supported branches on May 20, 2026, between 17:00 and 21:00 UTC. (To see this in your local timezone, refer to the Drupal Core Calendar.) The Drupal Security Team urges you to reserve time for core updates at that time because exploits might be developed within hours or days.

The risk is currently rated as:
Highly critical 20 ∕ 25 AC:None/A:None/CI:All/II:All/E:Theoretical/TD:Uncommon.

Not all configurations are affected. Reserve time on May 20 during the release window to determine whether your sites are affected and in need of an immediate update. Mitigation information will be included in the advisory.

We recommend updating to the latest supported patch (bugfix) release for your site's version of Drupal before May 20, so that you can address any other upgrade issues before the security window. (Recommendations for specific Drupal versions follow.)

This issue is being protected by Drupal Steward. Sites that use Drupal Steward are already protected from known attack vectors, but should upgrade in the near future in case additional attack vectors are discovered.

Affected versions Supported core versions

Security releases will be provided for all the currently supported branches of Drupal core, which are:

  • 11.3.x
  • 11.2.x
  • 10.6.x
  • 10.5.x

Sites on one of these supported versions should update to the latest patch release for the given branch now in preparation for the security window.

End-of-life minor core versions (Drupal 10 and 11)

While the Drupal Security Team does not normally provide security releases for unsupported releases, given the severity of the issue, we are providing 11.1.x and 10.4.x releases that include the fix for sites which have not yet had a chance to update. Therefore, in advance of the window:

  • Sites on Drupal 11.1 or 11.0 should update to at least Drupal 11.1.9.
  • Sites on Drupal 10.4, 10.3, 10.2, 10.1, or 10.0 should update to at least Drupal 10.4.9.

These sites should apply the security update as soon as it is released on May 20, then plan to update to Drupal 11.3 or 10.6 in the near future. (Two other recent security advisories, SA-CORE-2026-001 and SA-CORE-2026-002, will not be addressed for 11.1 or 10.4.)

End-of-life major core versions (Drupal 8 and 9)

These major versions are fully end-of-life, so no releases will be created for these branches. However, given the potential severity of this issue, we will provide patch files for Drupal 8.9 and 9.5.

These patches must be applied manually. They are not guaranteed to work correctly, and might introduce other bugs or regressions. However, they may help mitigate the vulnerability for sites still on these old major versions until they upgrade to a supported release.

For the best chance of the patches being applied successfully:

  • Sites on any version of Drupal 9 should update to Drupal 9.5.11.
  • Sites on any version of Drupal 8 should update to Drupal 8.9.20\.

We strongly recommend Drupal 8 or 9 sites update to at least Drupal 10.6 soon. Drupal 8 and 9 include numerous other, previously disclosed security vulnerabilities that will not be addressed by either Drupal Steward or the best-effort patch files.

Drupal 7 is not affected.

Disclosure policy

Neither the Security Team nor any other party is able to release any more information about this vulnerability until the announcement is made. The announcement will be made public at https://www.drupal.org/security, on Bluesky, Mastodon, X (formerly Twitter), and LinkedIn, and in email for those who have subscribed to our email list. To subscribe to the email list: log in on Drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.

Security release announcements will appear on the Drupal.org security advisory page which also has RSS feeds.

Coordinated By: 

Talking Drupal: Talking Drupal #553 - Saving The Open Web

Drupal Planet -

Today we are talking about The Open Web, What it means, and Why it's important with guest Alex Moreno. We'll also cover AI Schema.org JSON-LD as our module of the week.

For show notes visit: https://www.talkingDrupal.com/553

Topics
  • Defining the Open Web
  • Drupal in a Bubble
  • Marketing and PR Challenges
  • AI Bias Against Drupal
  • Why AI Won't Recommend Drupal
  • Is Drupal AI Native
  • Marketing Against Giants
  • Local Evangelism Push
  • Funding Outreach Trips
  • Drupal CMS PR Gap
  • Templates Lower Barriers
  • Need a Drupal Onramp
  • Speaking Beyond Drupal
  • Web Summit Lessons
  • Sell Problems Not Drupal
  • Rethinking DrupalCon
  • Camps and New Audiences
  • Marketplace Ecosystem Idea
  • Wrap Up and Contacts
Resources Guests

Alex Moreno - alexmoreno

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Bernardo Martinez - bernardm28

MOTW Correspondent

Jacob Rockowitz - jrockowitz.com jrockowitz

  • Brief description:
    • The AI Schema.org JSON-LD module provides a straightforward way to send a prompt — including a webpage's content and data, along with instructions and requirements — to an AI provider and receive a response containing valid Schema.org JSON-LD for saving and embedding in a webpage. It's a "glue module" that combines AI Automators, Field Widget Actions, and JSON Field to create an AI-powered Schema.org JSON-LD field for content entities.
  • Module name/project name:
  • Brief history
    • How old: Created in April 2026 by jrockowitz (Jacob Rockowitz) of The Big Blue House
    • Versions available: 1.0.0-alpha1 (requires Drupal ^11.3); 1.0.x-dev branch also available
  • Maintainership
    • Actively maintained Yes — updated as recently as April 30, 2026
    • Security coverage No — not currently covered by Drupal's security advisory policy; use at your own risk
    • Test coverage The module notes that all contributed code must include test coverage, though it is early alpha
    • Documentation Yes — the project page includes setup instructions, implementation guidance, philosophy, and a 2-minute demo video on YouTube
    • Number of open issues: 0 open issues, 0 of which are bugs against the current branch
  • Usage stats:
    • 1 site currently reporting use of this module
  • Module features and usage
    • Adds a native JSON "Schema.org JSON-LD" field to content entities (nodes, media, taxonomy terms)
    • Field is populated via an AI automator triggered by a Field Widget Action, keeping a human in the review loop before saving
    • Stores Schema.org JSON-LD as native JSON data, creating a fully queryable knowledge graph for the site
    • Works with complex nested content structures (paragraphs, components) by having AI parse and generate the structured data
    • Includes an optional sub-module for logging prompts and AI responses for human and AI review and iterative improvement
    • Configurable per entity type/bundle via UI, Drush, or Drupal recipe
    • Philosophy: "Use AI to build a tool that helps AI understand your website while always keeping a human in the loop"
    • Built using AI coding agents (Claude and Codex), with community contributions encouraged — especially around crafting and sharing optimal prompts

The Drop Times: A Structural Shift in Drupal Funding

Drupal Planet -

Among last week’s more closely watched Drupal business developments was a new initiative from Acquia that directs 2% of eligible partner-driven transactions to the Drupal Association. The contribution is built into Acquia’s updated partner programme and funded by the company itself, meaning partner incentives and customer pricing remain unchanged.

What drew attention across the community was not simply the contribution percentage, but the way the programme has been structured. Drupal funding conversations have often returned to the same pressure points around sponsorship cycles, institutional support, and long-term maintenance responsibilities. Acquia’s framing moves that discussion toward routine commercial activity rather than a separate community-facing commitment.

Both James Sims and Dries Buytaert described the initiative in terms of continuity and alignment rather than philanthropy. Their comments pointed to the same underlying argument: if commercial Drupal activity continues to scale, support structures around the project may also need models that scale more predictably alongside it.

Whether similar approaches emerge elsewhere remains uncertain. For years, much of Drupal’s organisational support has depended on periodic sponsorships and voluntary reinvestment. Acquia’s model, in contrast, ties funding directly to ongoing commercial activity, introducing a level of predictability that community funding discussions have often lacked.

With that said, here’s what else The Drop Times covered across the Drupal community last week.

DISCOVER DRUPALORGANIZATION NEWSOBITUARYBLOGEVENT

Additional developments from across the Drupal ecosystem were published during the week. Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook for ongoing updates. The publication is also active on Drupal Slack in the #thedroptimes channel.

Kazima Abbas
Sub-editor
The Drop Times

The Drop Times: Ten Technical Areas Shaping Enterprise Drupal Workflows in 2026

Drupal Planet -

Enterprise Drupal projects increasingly intersect with automation systems, cloud infrastructure, decoupled frontend development, and AI-assisted workflows as Drupal 11 adoption continues across larger platforms. Ongoing community discussions and architectural shifts around modern PHP, API-driven systems, and platform engineering also continue to expand the technical scope of Drupal development work.

LakeDrops Drupal Consulting, Development and Hosting: The Architecture That Changed the Game: Modeler API

Drupal Planet -

The Architecture That Changed the Game: Modeler API Jürgen Haas Mon 18 May 2026 - 12:10

The Modeler API completes the architectural separation between model owners (systems like ECA and Migrate) and modelers (visual UIs like BPMN.iO and Workflow Modeler). Module maintainers can now offer visual configuration without building custom UIs. The API automatically provides routing, permissions, save orchestration, import/export, testing, and Drush commands. This is infrastructure that compounds: 4 model owners × 3 modelers = 12 working combinations with zero glue code. Each new model owner makes every modeler more valuable, and vice versa. Designed at DrupalCon Atlanta in early 2025 and developed in the following months, the Modeler API positions Drupal ahead of competitors with architecture for visual configuration of any complex system.

DDEV Blog: Watch: DDEV From Scratch with macOS

Drupal Planet -

TL;DR This 30-minute video shows DDEV from zero to everything on a completely blank new MacBook Neo (exactly the same on any macOS device.)

Using Windows or Linux? See DDEV on Windows in 10 Minutes, DDEV on WSL2 from Scratch, or DDEV on Linux in 10 Minutes.

DDEV is a local development environment based on Docker containers that gets you up and working on your project fast. When you’re ready for additional configuration and customization, you won’t be starting from scratch and can lean on the expertise of the DDEV community.

In this screencast we walk through installing Homebrew, setting up OrbStack as a Docker provider, installing DDEV, and getting started with a basic project — all on a brand-new MacBook Neo with only 8GB of RAM. We use a Composer-managed Drupal 11 project as an example, and also cover setting up Xdebug with both PhpStorm and VS Code. The presentation slides are also available.

After watching this tutorial, you’ll be able to run websites on your computer with minimal configuration and have multiple sites with different configurations available locally, all because Docker does the heavy lifting while DDEV does the simplifying. Whether you’re a solo engineer or a member of a team, DDEV will help you be more efficient.

This screencast references the regular DDEV documentation:

Here’s the video table of contents (opens in YouTube):

  • What is DDEV (1:00)
  • Install Homebrew (3:01)
  • Install Docker provider (OrbStack) (5:07)
  • Install DDEV (7:54)
  • Create a trivial "junk" project (9:03)
  • Create a Drupal 11 project (11:42)
  • Learn a few DDEV commands (15:35)
  • Xdebug with PhpStorm (18:51)
  • Xdebug with VS Code (24:40)
  • DDEV Resources (30:40)

Dries Buytaert: The gap between Drupal and its reputation

Drupal Planet -

I saw two thoughtful posts in my LinkedIn feed over the last week that I wanted to reshare here before the LinkedIn feed buried them. Both were spot on, honest, and deserve a longer shelf life.

The first was from Hynek Naceradsky:

I'm pissed.

Not at Drupal. At the people confidently hating on it without ever having understood what it actually does.

"Drupal is outdated." "Drupal is too complex." "Nobody uses Drupal anymore."

Tell that to the EU institutions, governments, universities, and enterprises quietly running mission-critical platforms on it.

Here is what actually gets me though: the Drupal community lets this narrative win.

I am guilty of this too.

We literally have thousands of contributed modules, maintained for free, by people who owe you absolutely nothing. The security team responds faster than most paid vendors. The community has been showing up for 20+ years.

And yet we're somehow losing the PR war to frameworks that can't handle a proper content workflow without three paid plugins and a prayer.

Drupal people: talk louder. Write the posts. Go to the meetups. Tell the stories, fight for Drupal.

Because the Drupal community is honestly the best thing in Open Source, and both it and Drupal deserve way better than silence.

The second was from Thomas Scola, writing from a Drupal AI event in New York (lightly trimmed):

I overheard a couple people say, "Drupal? Is that still around?"

Hell yes it is.

And not only is it still around, I'd argue pretty heavily that Drupal is uniquely positioned for what comes next with the agentic web.

API-first before API-first was cool and trendy. Structured content that actually makes sense. Mature permissions, workflows, governance, integrations.

A lot of platforms are now scrambling to figure out how AI fits into what they already built.

Drupal doesn't have to force it. The architecture has been there.

But honestly, the tech is only part of it. The community is what always gets me. The people, passion and innovation. [...]

What comes next? Who knows.

But if I'm betting on a community to adapt, build, and help define that future, I'm putting my money on this one, and on what we've all built together.

For a platform people love to ask if it's "still around", it feels more relevant than ever.

I could not agree more with both posts. Drupal is one of the strongest Open Source platforms out there right now, but too few people realize it. The Drupal community has been modernizing the platform faster than its reputation evolves.

If the loudest narrative about Drupal is that it is outdated, people will keep repeating it, even when it is wrong. AI systems will too, because they absorb the same narratives, blog posts, forum threads, and social chatter the rest of the industry does.

The danger is not just that Drupal is misunderstood today. It is that the gap between what Drupal actually is and how people perceive it may be growing, not shrinking.

The narratives we reinforce today become part of how AI describes Drupal tomorrow. Drupal's silence today becomes tomorrow's AI consensus.

So if you're in the Drupal community, take Hynek's advice and help set the record straight. Not for AI, but for people. Write about the great work happening in Drupal: share the case studies, the technical breakthroughs, the AI innovation, and the hard problems being solved every day.

I know many people in Open Source dislike marketing or self-promotion. I do too, sometimes. But if we don't document what is great about Drupal, others will define Drupal for us.

Every accurate case study, technical blog post, demo, or success story helps future developers, evaluators, and AI systems understand what Drupal actually is.

Drupal does not need hype. It needs a better public record.

Pixelite: Bots, scrapers, and proxies: defending Drupal sites in an automated internet

Drupal Planet -

Over half of all web traffic in 2024 was automated. That is the headline number from the Imperva 2025 Bad Bot Report, and it is the first time bots have outnumbered humans in more than a decade. Drupal sites sit squarely in that traffic mix, and the old defensive playbook — block an IP, ban a user agent, drop a robots.txt entry, lean on Fail2ban — does not hold up anymore.

This is the companion post to my DrupalSouth Wellington 2026 talk, Bots, scrapers, and proxies: defending Drupal sites in an automated internet. The talk walked through the defences I actually use at amazee.io and recommend on client sites. The post covers the same ground, with a bit more room to show config and link out to the projects.

What actually changed

The technical context underneath bot defence has shifted in three ways that matter:

  • Residential proxy networks. Scrapers no longer come from a handful of cloud subnets you can block. They route through real consumer IP addresses, often unwittingly donated by free-VPN users or piggy-backed off shady SDKs in mobile apps.
  • Headless browsers everywhere. Playwright and Puppeteer have made it trivial to render JavaScript-heavy pages at scale. A page that needed a real human five years ago can be scraped today by anyone with a laptop.
  • AI-driven scraping. Volume is up sharply because every new LLM needs training data, and there is now a steady drip of new crawlers showing up. Meta's externalagent is one recent example. There will be more.

Mimicry is now the baseline, not the edge case. A modern scraper will rotate IPs, randomise user agents, replay realistic TLS fingerprints, and pace itself slowly enough to look like a real user. You cannot rely on signal that lives in one HTTP header.

The scale of it

If this still sounds like a niche problem, the numbers say otherwise.

  • 51% - share of web traffic that was automated in 2024, per the Imperva 2025 Bad Bot Report.
  • +96% - year-on-year growth in some popular bot services across Pantheon's hosting fleet in their July 2025 data.
  • 1B+ - unique monthly visitors Pantheon sees across its platform, which is the size of dataset those numbers are coming from.

On the amazee.io platform globally, 13% of incoming requests can be flagged as non-human based on the user agent alone. That is the lazy bots. The actual share of automated traffic is higher once you account for the ones that try to blend in. In absolute terms it adds up to hundreds of millions of requests every month.

The goal is not to block all bots

Before going through the defences, one thing I am careful to say up front, both on stage and here: the goal is not to block all bots. That is unwinnable, and the closer you get to it the more real users you break.

Search crawlers, RSS readers, uptime monitors, link-preview generators in Slack and iMessage, accessibility tooling - all bots, all wanted. The goal is to reduce abuse where it hurts most, on the endpoints that cost you real money or real performance, while leaving everything else alone.

Drupal-native defences

The defences closest to your application are the smartest. They can see the path, the user, the form, the cache state. They are also the most expensive per blocked request, because every block at this layer has already cost you a full PHP bootstrap.

Perimeter

The Perimeter module drops requests matching known-bad patterns: /wp-admin, /.env, xmlrpc.php, all the WordPress scanner noise that hits every Drupal site daily. It is the cheapest win on the list. It will not stop a serious scraper, but it will keep your logs clean and your error rate honest.

CrowdSec and AbuseIPDB

CrowdSec is a local agent plus a community blocklist. Every site running CrowdSec contributes detected attacks back to a shared signal, and pulls down the latest list of bad actors. It is the closest thing the open-source world has to a distributed reputation system.

AbuseIPDB is a reputation lookup service. You query an IP, you get a confidence score. It is most useful on the forms and login flows where you can afford the latency of an external API call. Both are available as Drupal modules.

Facet Bot Blocker

If you run Search API with facets, this is the single cheapest huge win available to you. Faceted search URLs are catnip for scrapers: every combination of filters is a new URL, every URL is uncached, every uncached request hits the database. A bot that crawls a faceted listing can take a site down without trying.

The Facet Bot Blocker module acts as a rate limit on requests that include at least one facet in the URL. Configure it to use Redis or memcache for the counter so you are not making the problem worse by hitting the database to record the request. On one of our hosting customers, this one module cut Search API load by more than half.

Form-side defences

Logins, registrations, password resets and contact forms all need their own treatment, separate from page-level defence:

  • Honeypot - invisible field plus a time-based check. Cheap, fast, surprisingly effective against the dumb half of form spam.
  • Antibot - requires JavaScript to submit, blocks the bots that do not run JS.
  • CAPTCHA, reCAPTCHA, or Cloudflare Turnstile - full challenge. Use the lightest option that works, and ideally only after Honeypot and Antibot have already rejected the easy cases.
  • Hidden CAPTCHA - bridges the gap when you want a CAPTCHA-style check without the accessibility cost of a visible challenge.
The trade-off the project pages don't mention

Every block at the Drupal layer has already cost you a PHP bootstrap. That is fine when the absolute volume is small. It is not fine when you are eating hundreds of millions of bot requests and bootstrapping PHP for each one. This is why you cannot stop at the application layer.

Web server and infrastructure

One layer out, the web server can drop requests before PHP ever runs. The trade-off flips: you save the bootstrap cost, but you lose access to application context.

Rate limiting and geo blocking

nginx ships with limit_req_zone, Apache has mod_ratelimit. Both are blunt but effective on volume. A starting point for nginx looks roughly like this:

limit_req_zone $binary_remote_addr zone=search:10m rate=10r/m; location /search { limit_req zone=search burst=5 nodelay; proxy_pass http://drupal; }

Ten search requests per minute, per IP, with a burst of five. Tune to taste. The $binary_remote_addr key is cheap on memory; a 10MB zone holds around 160,000 IPs.

Geo blocking is the other infrastructure-level lever. It is pragmatic and occasionally controversial. If your audience is the New Zealand public sector, blocking inbound from regions you do not serve is a defensible call. If your audience is global, it is not. Know your traffic before reaching for it.

ModSecurity and the OWASP CRS

ModSecurity with the OWASP Core Rule Set is a proper WAF you can self-host. Once tuned, it is real protection. The tuning is the catch — out of the box it will flag Drupal admin actions, file uploads, anything that looks like SQL in a body or a query string. Expect to spend real time pruning rules and adding exceptions for legitimate site behaviour before you stop generating false positives.

Cache discipline

A request that hits the cache costs you nothing. Whatever else you do, get your cache headers right. Vary on the bits that need to vary, cache aggressively on the bits that do not, and lean on the page cache or the reverse proxy in front of Drupal. The cheapest bot is the one that asks for a page you have already served.

(shamless plug) you can also use my site Caching Score to review your current caching setup, to see if there is anything better you can be doing.

Caching ScoreAssess how strong the caching capabilities of any given site is.Caching Scoresean.hamlinamazee.ioWhat this layer is bad at

Rate limits, ModSecurity rules and geo blocks are great at volume and bad at quality. They cannot tell a scraper trickling one request per minute apart from a real user. For that you need either the edge or the application.

Edge and paid bot management

The edge is where the big vendors live, and it is where you push the cheapest blocks. A scraper rejected by Cloudflare at the network edge never gets to your origin at all.

Cloudflare

The free tier already includes Bot Fight Mode, basic challenges, and Turnstile. For most small-to-medium Drupal sites, this is a good baseline at zero extra cost. The paid Bot Management product adds custom rule logic, JA3 and JA4 TLS fingerprinting, and machine-learning-based bot scoring you can wire into firewall rules. The jump from free to paid is significant in price; the jump in capability is also significant.

Fastly, Akamai, and the rest

Fastly offers the Next-Gen WAF (originally Signal Sciences) with a Bot Management add-on. Akamai sits at the enterprise tier with the most sophisticated fingerprinting available, and a price tag to match. Beyond those, there is AWS WAF with Bot Control, DataDome, HUMAN, and Imperva — all credible, all paid, all priced for sites where bot abuse is costing real money.

The trade-offs nobody puts on the sales deck

Bot Management at the edge solves real problems. It also comes with real costs that the vendor demos skip past:

  • Cost. Bot Management is almost always an add-on to the core WAF subscription, and the pricing escalates fast with traffic.
  • Vendor lock-in. Your rules, your dashboards, your observability all live in the vendor's UI. Migrating off is painful.
  • Accessibility and SEO. Aggressive challenges break real users, and search bots that fail a challenge will hurt your rankings. Test both before turning anything up.
  • Rules live outside your application codebase. They drift, they are not versioned alongside the code that depends on them, and a rule change can break a feature without any commit to point to.
  • False positives are invisible to you. By default, blocked requests do not reach your logs. You will not know which real users were turned away unless you specifically ask for that signal.
Anubis

The newest piece in the picture, and the one that has me genuinely interested.

What Anubis is

Anubis is an open-source reverse proxy (MIT licensed) that sits in front of your site and issues a proof-of-work challenge to clients before letting them through. It was built specifically for the AI scraper era — for the case where the scraper is mimicking a real browser well enough that classifying it on signal alone has stopped working.

Why proof-of-work, not CAPTCHA

The interesting move with Anubis is who pays the cost. A real user pays a few hundred milliseconds of CPU once when they first arrive, and never sees it again for the lifetime of the cookie. A scraper hitting you a million times pays the cost a million times.

That asymmetry is the whole point. CAPTCHAs put the cost on humans (the people who lose patience trying to identify traffic lights). Anubis puts it on whoever is doing the hammering. That is closer to the right shape of the trade.

Where to put it

You do not want Anubis in front of your whole site. You want it in front of the endpoints that are expensive and uncacheable. From the talk, my shortlist:

  • Search endpoints
  • Facet and filter URLs
  • Pagination tails - ?page=2348 is not a real user
  • Login, register, password reset
  • Spicy forms (contact, anything that triggers an email)
  • Authenticated user flows
  • Anything expensive and uncacheable

Static pages stay fast. The cache stays warm. The PoW cost only applies on the routes where it earns its keep.

But what about Googlebot?

This is the first question every site owner asks, and the answer is good. Anubis ships with allowlists for known good crawlers, matching IP ranges against the published lists from Google, Bing, and the rest. The allowlist is maintained upstream, which means you need to keep Anubis deployed on a reasonable cadence to pull in the latest changes. New legitimate crawlers do show up.

Demo site

You can see Anubis in action with a demo Drupal 11 site I put together, the login form has Anubis in front of it, the homepage does not.

Log in | Drush Site-InstallDrush Site-InstallPutting the layers together

None of these defences is a silver bullet on its own. Each layer is cheap at one thing and bad at another, and the trick is matching the layer to the threat.

Layered defence diagram showing requests flowing from clients through Edge/CDN, Anubis, web server, and Drupal, with cost-to-block increasing as you move closer to the application.

Block the cheap traffic at the edge. Block the lazy bots with rate limits and ModSecurity at the web server. Put Anubis in front of the endpoints that are expensive and uncacheable. Let Drupal-native modules handle the application-aware decisions where you actually need to see the user, the form, or the facet state.

Five things to take away
  1. No single layer is enough. Stack them. The edge handles raw volume, the web server handles patterns, and the application is the only thing that can see real user and form context.
  2. Match the protection to the threat. A login form needs different defence to a faceted search results page.
  3. Measure before you defend. Look at your actual traffic. Find your most-hit uncacheable endpoints. Defend those first.
  4. Watch accessibility and SEO. Every challenge you add is a tax on a real user or a real crawler. The cost of false positives is invisible unless you go looking.
  5. Plan for adversarial improvement. Whatever you deploy today, the scrapers get a turn next. Pick defences you can iterate on.
One last thing

You do not need to win the bot war. You just need to make your site a worse target than the next one.

The slides from the talk are on the DrupalSouth schedule page. The recording will be posted here once the DrupalSouth team have edited and uploaded it — check back in a few weeks.

Pages

Subscribe to www.hazelbecker.com aggregator - Drupal feeds