<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Security — Articles | WebPro Company OÜ</title>
    <link>https://webpro.company/blog/tag/security/</link>
    <atom:link href="https://webpro.company/blog/tag/security/rss.xml" rel="self" type="application/rss+xml" />
    <description>Drupal security — permissions, module health, updates and technical risks that need regular review.</description>
    <language>en-US</language>
    <lastBuildDate>Sat, 20 Jun 2026 06:00:00 GMT</lastBuildDate>
    <item>
      <title>Drupal 7 Migration Statistics in 2026: What the Numbers Really Mean</title>
      <link>https://webpro.company/blog/drupal-7-migration-statistics-2026</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-7-migration-statistics-2026</guid>
      <pubDate>Sat, 20 Jun 2026 06:00:00 GMT</pubDate>
      <category>Migration</category>
      <category>Drupal</category>
      <category>Audit</category>
      <category>Security</category>
      <description>A Drupal 7 migration in 2026 should not be treated as a simple technical upgrade. The statistics point to a wider operational risk that requires audit work, budgeting, content migration planning, and editorial interface decisions. Drupal 7 Has Not Disappeared, Even Though Official Support Has Ended Official security and compatibility support for Drupal 7 ended on 5 January 2025. Drupal.org explains on its Drupal 7 End of Life page that Drupal 7 no longer receives regular community security or compatibility updates after that date. In 2026, the question is no longer whether Drupal 7 will reach end of life. It already has. Public usage data still shows that many websites have not yet moved to a newer Drupal version or another platform. According to Drupal.org usage statistics, more than…</description>
    </item>
    <item>
      <title>Drupal scanner: a public pre-check before maintenance or upgrades</title>
      <link>https://webpro.company/blog/drupal-scanner-public-precheck</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-scanner-public-precheck</guid>
      <pubDate>Sun, 24 May 2026 06:00:00 GMT</pubDate>
      <category>Drupal</category>
      <category>Audit</category>
      <category>Security</category>
      <description>The real state of a Drupal website is best checked with access to code, logs, configuration and the database. A public scanner still helps reveal visible warning signs quickly. The WebPro Drupal scanner is a simple public pre-check. You enter a website address, start the scan and get a first view based on information visible from the outside. It does not log in, change the site or require credentials. The result is not an official audit and it does not prove that a site is safe. A lower result means only that public data did not show an obvious high-risk signal. If you do not know when the site was last updated, it should be checked properly. What it checks The scanner looks for signals that are often visible without logging in: public Drupal and PHP traces; Drupal and PHP support…</description>
    </item>
    <item>
      <title>Why an old website can be a business risk</title>
      <link>https://webpro.company/blog/why-an-old-website-can-be-a-business-risk</link>
      <guid isPermaLink="true">https://webpro.company/blog/why-an-old-website-can-be-a-business-risk</guid>
      <pubDate>Tue, 07 Apr 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Security</category>
      <description>An old website is not only a problem when it breaks. Often the real risk is that nobody can change it safely anymore. What risks accumulate Security risk is the most visible one, but not the only one. An ageing website can affect sales, recruitment, customer support and legal compliance. Typical risks include: software no longer receives security fixes; forms or checkout do not work in all browsers; content management depends on one person; WCAG requirements are not met; a new developer cannot understand the system quickly. How to choose the next step Not every old website needs immediate rebuilding. Sometimes maintenance and small fixes are enough. In other cases, it is cheaper to plan migration before the issue becomes an emergency. WebPro helps choose the path through audit and…</description>
    </item>
    <item>
      <title>Drupal security updates — why they cannot be postponed</title>
      <link>https://webpro.company/blog/how-drupal-security-updates-work</link>
      <guid isPermaLink="true">https://webpro.company/blog/how-drupal-security-updates-work</guid>
      <pubDate>Sat, 28 Mar 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Security</category>
      <category>Drupal</category>
      <description>Drupal has one of the more mature security processes among open-source CMS platforms. But applying a security update is not simple — it is technical work that requires planning. Many website owners assume that &quot;updating&quot; means pressing a button. In Drupal projects, that is not how it works — and for good reason. Understanding how security updates work helps explain why regular maintenance is technical work, not an automated process. The Drupal Security Team Drupal has a dedicated volunteer security team responsible for evaluating vulnerabilities and publishing security advisories. The process works as follows: Someone reports a vulnerability privately to the Security Team. The team assesses severity and coordinates a fix with the module maintainer. On a scheduled date, the fix and the…</description>
    </item>
    <item>
      <title>Drupal roles, permissions and editorial workflow</title>
      <link>https://webpro.company/blog/drupal-roles-permissions-and-editorial-workflow</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-roles-permissions-and-editorial-workflow</guid>
      <pubDate>Tue, 24 Mar 2026 06:00:00 GMT</pubDate>
      <category>Security</category>
      <category>Drupal</category>
      <description>Drupal allows very detailed role and permission management. That is exactly why permissions should be reviewed regularly instead of leaving years of exceptions in place. Common problems Drupal user and permission management fits complex organisations, but poor configuration can grant too much access or make editing difficult. Check: whether former employees still have access; whether editor roles see only the tools they need; whether administrator permissions are used too broadly; whether the publishing workflow is documented; whether forms and files are properly restricted. Why this belongs in maintenance A permissions audit should not wait for a security incident. It is worth doing with a larger update, a new editorial workflow or a provider change. WebPro reviews roles and…</description>
    </item>
    <item>
      <title>What happens when a Drupal site is not updated</title>
      <link>https://webpro.company/blog/what-happens-when-drupal-is-not-updated</link>
      <guid isPermaLink="true">https://webpro.company/blog/what-happens-when-drupal-is-not-updated</guid>
      <pubDate>Sat, 14 Mar 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Security</category>
      <category>Drupal</category>
      <description>Nothing happens to an unmaintained Drupal site — until something does. Accumulating known vulnerabilities, ageing dependencies and rising remediation costs are real consequences, not theoretical risks. An unmaintained site often runs for years with no visible problems. This creates a false sense of security: if everything works, why update? In reality, every unpatched month adds risk that is invisible until it materialises. Security vulnerabilities accumulate Drupal publishes security patches regularly — roughly once a month. Each patch resolves specific known vulnerabilities. When a patch is not applied, the vulnerability stays open. What makes this especially critical is that security flaws are disclosed after the patch is released. This means attackers know exactly which versions…</description>
    </item>
    <item>
      <title>How to check if a Drupal module is risky</title>
      <link>https://webpro.company/blog/how-to-check-if-a-drupal-module-is-abandoned-or-risky</link>
      <guid isPermaLink="true">https://webpro.company/blog/how-to-check-if-a-drupal-module-is-abandoned-or-risky</guid>
      <pubDate>Tue, 17 Feb 2026 06:00:00 GMT</pubDate>
      <category>Security</category>
      <category>Drupal</category>
      <category>Audit</category>
      <description>A Drupal module can solve a problem quickly, but the wrong module can later make updates, security patching and migration difficult. What to check before installation A Drupal module page usually shows maintainers, releases, the issue queue and security coverage. Drupal.org module documentation gives background, but the decision depends on the project. Check: when the last stable release was published; whether the module supports your Drupal version; whether the issue queue shows active maintenance; whether the module is covered by Drupal security advisories; how much custom code the module adds to your project. When to choose another route If a module has no maintainer or the upgrade path is unclear, a cheap solution can become expensive later. Sometimes it is better to use another…</description>
    </item>
    <item>
      <title>PHP version and Drupal hosting</title>
      <link>https://webpro.company/blog/php-version-and-drupal-hosting</link>
      <guid isPermaLink="true">https://webpro.company/blog/php-version-and-drupal-hosting</guid>
      <pubDate>Fri, 06 Feb 2026 06:00:00 GMT</pubDate>
      <category>Maintenance</category>
      <category>Drupal</category>
      <category>Security</category>
      <description>A website may appear to work while the server already runs an outdated PHP version. That quiet risk should be visible before major upgrades. Drupal depends on PHP Drupal is written in PHP. This means Drupal security and reliability also depend on the PHP version running on the server. The official PHP site lists supported PHP versions. If the server uses a version that no longer receives security fixes, updating Drupal modules is not enough. The site may still work. The risk is that old PHP blocks future upgrades and may leave security issues without fixes. What to check in hosting At the start of Drupal maintenance, hosting should be checked together with Drupal itself. The important questions are simple: which PHP version is used; whether the server allows a newer PHP version;…</description>
    </item>
    <item>
      <title>Drupal 7 in 2026: what to do with an old site</title>
      <link>https://webpro.company/blog/drupal-7-in-2026-what-to-do</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-7-in-2026-what-to-do</guid>
      <pubDate>Tue, 06 Jan 2026 06:00:00 GMT</pubDate>
      <category>Migration</category>
      <category>Drupal</category>
      <category>Security</category>
      <description>A Drupal 7 website can still look fine in 2026, but official security support has ended and every new change is becoming harder to control. Why this is no longer a normal update Drupal 7&apos;s official lifecycle has ended. That means an old site does not only need module updates. It needs a decision: continue with known risk, buy temporary support or move to a newer platform. Module updates have stopped. If a new security vulnerability is found in a Drupal 7 module, no automatic fix will arrive — someone must patch it manually or accept the risk. What the real risks are Most Drupal 7 sites are still running without any visible problem. The risk does not appear immediately — it grows over time: Security vulnerabilities — newly found weaknesses in modules are no longer patched automatically.…</description>
    </item>
    <item>
      <title>Drupal security in practice — what actually happens when you skip updates</title>
      <link>https://webpro.company/blog/drupal-security-in-practice</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-security-in-practice</guid>
      <pubDate>Thu, 06 Feb 2025 06:00:00 GMT</pubDate>
      <category>Security</category>
      <category>Drupal</category>
      <category>Maintenance</category>
      <description>Drupal security updates feel like tedious routine — until the day your site is compromised. Here is the real picture of what happens and how to protect yourself. What attackers do with Drupal sites A compromised Drupal site does not necessarily &quot;break&quot; — an attacker&apos;s goal is often not to destroy the site. The goals are: Malware distribution — hidden code is added to the site that loads malware onto visitors&apos; computers. The site works normally, the owner notices nothing — but Google notices and adds the site to its blacklist. SEO spam — hidden pages are added advertising pharmaceuticals, gambling or other illegal content. Google indexes these pages under the site&apos;s domain. Result: the site&apos;s SEO reputation is damaged. Botnet member — the compromised server is added to a botnet used to…</description>
    </item>
    <item>
      <title>Drupal security incident plan — what to do when your site is compromised</title>
      <link>https://webpro.company/blog/drupal-security-incident-plan</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-security-incident-plan</guid>
      <pubDate>Thu, 16 Jan 2025 06:00:00 GMT</pubDate>
      <category>Security</category>
      <category>Drupal</category>
      <category>Maintenance</category>
      <description>During a security incident there is no time to start planning. Here is a step-by-step guide that every Drupal site owner should prepare in advance. Why the plan must exist before the incident When a site is compromised, you are stressed, clients are calling and every minute counts. That is not the moment to start figuring out what to do. A security incident plan is a document that answers questions before they are asked. The plan does not have to be long. It has to be clear and accessible — ideally not stored on the server being attacked. Signs of a security incident Before responding, you need to recognise that an incident has occurred: Google flags the site as &quot;this site may be harmful&quot; Hosting sends a notification about suspicious activity Unknown pages or redirects appear on the…</description>
    </item>
    <item>
      <title>Drupal backup restore test — why &quot;backup exists&quot; is not enough</title>
      <link>https://webpro.company/blog/drupal-backup-restore-test</link>
      <guid isPermaLink="true">https://webpro.company/blog/drupal-backup-restore-test</guid>
      <pubDate>Thu, 02 Jan 2025 06:00:00 GMT</pubDate>
      <category>Security</category>
      <category>Drupal</category>
      <category>Maintenance</category>
      <description>A backup that has never been restored is an untested hypothesis. Here is how to make sure your Drupal backup actually works. A backup is a promise, not a guarantee Nearly everyone has a backup. Hosting providers take nightly snapshots, some use scripts, others rely on modules like Backup and Migrate. But the question is not whether a backup is being made — the question is whether it works. A backup that has never been restored is an untested hypothesis. A restore test is simple: take a backup and restore it. See whether the result is a usable site. What a backup must contain A complete Drupal backup consists of two parts: Database — all Drupal content, configuration, users. Without the database there is no site. Files — the directory. This is where images, documents and uploaded files…</description>
    </item>
  </channel>
</rss>
