WordPress Security: Top Threats, Challenges, and How to Protect Your Site

WordPress Popularity and the Scale of Cyber Threats

WordPress is the most widely used content management system (CMS) in the world—powering more than 43% of all websites on the internet and holding about 60% of the entire content management systems market ^{[1, 2]}. Its open-source nature, broad spectrum of functionality, and active community significantly contribute to this popularity ^[3]. However, such widespread use of WordPress inevitably attracts greater attention from cyber attackers.

Various types of websites—from e-commerce platforms to corporate representative pages—are increasingly becoming targets of cyber attacks due to the valuable data stored in them, such as customers’ personal information, payment data, login credentials, or corporate commercial information ^{[4, 5]}. Yet even sites that do not directly collect sensitive information can be compromised: they can be used to distribute malicious code, included in fraud schemes, leveraged for disinformation spread, or to cause reputational damage ^{[6, 7, 8]}. The consequences of successful attacks can include not only direct financial losses but also long-term damage to the organization’s image, loss of customer trust, and the risk of getting blacklisted by search engines like Google, which significantly reduces the website’s accessibility ^{[9, 10, 11]}.

Cybersecurity incident statistics show that the WordPress platform remains one of the primary targets for cyber attacks. A 2023 report by the cybersecurity company Sucuri indicates that WordPress accounted for 95.5% of all compromised websites analyzed by the company. Meanwhile, other popular content management systems, such as Joomla and Magento, accounted for 1.7% and 0.6% of incidents, respectively ^[12].

When comparing popular content management systems by the number of vulnerabilities assigned to them, based on records from the CVE (Common Vulnerabilities and Exposures) vulnerability database, significant differences also emerge. As of June 2025 data, over 24,500 vulnerabilities are attributed to the WordPress system, whereas Joomla has around 1,400, Magento – about 420, PrestaShop – about 280, and OpenCart – about 50 ^[13].

However, it is important to emphasize that the high percentage of WordPress incidents and the large volume of vulnerability records do not necessarily indicate fundamental security flaws in the platform itself compared to other systems. This rather reflects the consequences of its exceptional popularity and massive scale of use—the more popular a system is, the more likely it is to statistically become a target for cyber attacks.

Plugins and Other Security Solutions

The vast popularity of WordPress also implies certain positive security aspects. Widely used technologies naturally attract greater attention from IT security researchers, become frequent subjects of investigation, and encourage the development of specialized cybersecurity solutions. This trend aligns with the so-called popularity hypothesis, which asserts that the more widely software is used, the more intensively it is investigated and tested ^[14]. From this perspective, the large number of WordPress vulnerability records does not necessarily indicate a weaker security level—on the contrary, it can be viewed as an indicator of active security analysis and community involvement. The intensity of research creates preconditions for identifying risks in a timely manner, informing users and software developers about discovered flaws, and implementing preventive measures that contribute to strengthening the resilience of the entire ecosystem. Nevertheless, technology’s popularity alone does not allow for unequivocal conclusions about its security level.

Furthermore, the WordPress security ecosystem is complemented by specialized plugins designed for protection against various cyber threats. One of the most well-known is Wordfence, developed by the US company Defiant, while other widely used plugins include All-In-One Security, MalCare, Sucuri Security, Jetpack, Patchstack, and others. These plugins feature different functionalities, but depending on the chosen solution, they often encompass security measures such as login system protection, a firewall, vulnerability monitoring, and malicious code detection ^{[15, 16, 17, 18]}. There are also numerous niche plugins oriented toward specific security aspects, such as protection against automated bots or enabling two-factor authentication, so the variety of solutions allows website administrators to flexibly adapt security measures according to individual needs and risk assessments. This abundance of supply is illustrated by the fact that in the official WordPress plugin directory, about a thousand different plugins are tagged with the „security” label ^[19]. 

The effectiveness of specialized security solutions is confirmed by published data. For instance, the 2024 Wordfence annual report states that over 54 billion malicious requests were blocked during the year ^[20]. Meanwhile, the WordPress-related blog WPBeginner reported that during their first three months of using the Sucuri firewall, about 450,000 harmful requests were stopped on their website ^[21]. Additionally, a 2023 Jetpack Scan analysis identified over 70,000 WordPress sites where at least one malicious file was detected—most cases being associated with leaked login credentials or the use of unlicensed and modified (so-called „nulled”) software ^[22]. This not only underscores the importance of protection measures but also reveals the scale of cyber threats.

In addition to the previously mentioned security solutions, Wordfence and Patchstack also actively contribute to fostering a culture of responsible vulnerability disclosure. Through their bug bounty programs, they encourage security researchers to report discovered flaws in exchange for financial rewards. The results of Wordfence’s first year of program operations show the significant impact of this initiative: over 4,400 vulnerabilities were verified and $450,000 USD in bounties paid out. Currently, the program offers payouts of up to $31,200 USD for particularly high-impact vulnerabilities ^[23]. Based on May 2025 data, Patchstack has paid researchers more than $255,000 USD since 2022, with the maximum bounty for an uncovered vulnerability reaching up to $14,400 USD, depending on the severity of the security flaw ^[24]. WordPress itself also runs a responsible vulnerability disclosure program—security flaws in the system can be reported via the HackerOne platform ^[25].

Such vulnerability disclosure initiatives stimulate more active engagement from security researchers and shape a collaborative approach to software development. They help identify and patch vulnerabilities more quickly before they can cause real damage, thus strengthening the resilience of the entire WordPress ecosystem and user confidence in the platform’s security.

Vulnerability Dynamics and Main Challenges

Reviewing the annual vulnerability reports of two organizations operating in the WordPress security field—Patchstack and Wordfence—a significant growth in the number of detected flaws is noticeable. In its 2024 report, Patchstack indicated having identified 7,966 new security vulnerabilities in the WordPress ecosystem, which is 34% more than in 2023 ^[26]. Meanwhile, Wordfence’s 2024 report provided an even higher number—8,223 new flaws—and notes a 68% increase compared to the previous year ^[20]. Although the specific figures may vary due to different data collection methodologies or scopes, both sources unequivocally point to an upward trend in the number of vulnerabilities.

Evaluating the website cybersecurity situation in Lithuania, data from the National Cyber Security Centre (NKSC) shows that the vulnerability of „.lt” domain websites operating on content management systems has been a cause for concern for several years. In 2018, 52% of such websites were rated as vulnerable, with the majority of them using the WordPress CMS ^[27]. Subsequent data shows a similar situation: in 2019 – 63%, in 2020 – 56%, and in 2021 – 50% of sites used insecure and unupdated software due to known security flaws. Furthermore, the true scale of risk may be even larger, as some websites use software no longer supported by developers. NKSC reports note that the share of such websites lacking the ability to receive security updates was 8% in 2019, 6.5% in 2020, and 10% in 2021 ^{[28, 29, 30]}. These figures confirm that inadequate maintenance and a lack of updates remain among the most critical causes of website vulnerability in the Lithuanian web space.

One of the primary causes of WordPress security challenges is its open-source nature and the large community of third-party developers. These factors not only allow the system to grow and improve rapidly but also increase its vulnerability. Because any developer is free to create add-on components—both themes and plugins—their development, maintenance, and security levels vary. Such diversity significantly increases the risk that some components may be insufficiently secure and vulnerable.

This vulnerability risk arising from component diversity is further substantiated by the latest statistical data. Patchstack and Wordfence agree in their 2024 reports that 96% of all detected security flaws were found precisely in plugins, and the remaining portion (about 4%) in themes ^{[20, 26]}. This is also confirmed by the 2024 National Cyber Security Centre report, which notes that significant attention was paid to the security of WordPress CMS plugins—they frequently become targets for hackers due to inadequate protection and untimely updates ^[31].

Conversely, within the core software of the WordPress content management system itself, only a small number of flaws were identified in 2024—just 5 (according to Wordfence data) or 7 (according to Patchstack data). It is important to emphasize that none of these core flaws were considered critical or posed a significant threat. As Wordfence states, this is a good indicator of WordPress core maturity and clearly demonstrates that plugins are the main threat to WordPress website security ^{[20, 26]}.

Software developers’ responses to discovered security flaws raise additional concerns. According to Wordfence data, at the beginning of 2025, approximately 35% of all flaws discovered in 2024 were still unpatched. While this shows that most developers do react, more than a third of vulnerabilities remain open for a long time. Patchstack states that over 50% of plugin developers who were notified about a flaw failed or did not react to patch it prior to the public disclosure of the vulnerability ^{[20, 26]}. Slow responses or complete disregard of discovered vulnerabilities increases the likelihood that these flaws will be exploited. Therefore, the choice of plugins and themes should be based not only on their functionality but also on security aspects. It is recommended to prioritize components that are regularly updated, have numerous positive reviews, and are produced by reliable developers.

Security Assurance as a Continuous Process

However, ensuring security is not a one-time action—it is a continuous, constantly evolving process requiring systematic monitoring, adaptation, and risk management. Absolute security is impossible to achieve, especially in a rapidly changing cyber threat environment. In this context, the so-called „defender’s dilemma” is often highlighted—the defender must secure all potential weak points, while the attacker only needs to exploit a single flaw. However, to form an effective security strategy, it is also worth considering the „attacker’s dilemma”—a successful attack requires consistently overcoming multiple layers of defense while acting with limited information and constantly risking detection ^[32]. This perspective shows that it is not only important to understand one’s own weaknesses but also to actively exploit the limitations of cyber attacks’ execution. Preventive, multi-layered defense based on continuous monitoring, vulnerability assessment, and quick response allows for significantly reducing risks and increasing infrastructure resilience. 

This article provides examples of security recommendations intended to help form a reliable foundation for WordPress website protection. It should be noted that the software code fragments presented in the text are not definitive or universally applicable in all cases—they are intended for illustrative use and orientational guidelines. Additionally, the list of plugins, technological solutions, or configuration practices discussed here is not exhaustive; the selected tools reflect more commonly applied or representative examples.

The goal of the article is not to present a single final or comprehensive protection scenario, but to encourage critical evaluation of existing security measures, identify potential vulnerability points, and draw attention to areas that could receive greater focus. The discussed measures should be evaluated in context—taking into account the specific website’s infrastructure, management capabilities, and imposed security requirements.

Regular Updating of WordPress Core, Themes, Plugins, and Server Software

Timely deployment of software updates is a crucial factor in ensuring information system security. Although software developers issue security patches when a vulnerability is discovered, their practical effectiveness depends on whether site administrators install these updates in time. Publicly disclosed information about security flaws becomes accessible not only to administrators but also to cybercriminals. For this reason, a critical time gap emerges during which even already-patched vulnerabilities can become targets of attack if systems are not updated promptly.

How rapidly publicly disclosed security vulnerabilities turn into real threats is illustrated by the VulnCheck analysis from the first half of 2025. During this period, 432 security flaws were identified whose exploitation was confirmed in real-world cyber attacks (exploited in the wild). It was found that 32.1% of them were actively exploited within the first 24 hours of their official announcement, and in some cases—even before public disclosure of the vulnerability. This indicator grew significantly compared to 2024, when it reached 23.6% ^[33].

The dangerous trend of vulnerability exploitation is also confirmed by the Patchstack report from the first half of 2025. It stated that as many as 6,700 security flaws were identified in the WordPress ecosystem, of which 41% were exploited in real-world attacks ^[44]. These data show that untimely software updates drastically increase the probability of becoming a cyber target, hence systematic update deployment remains one of the most important security practices.

Nevertheless, insufficient management of CMS updates remains one of the primary security problems. For example, a 2023 Sucuri report noted that a staggering 39.1% of analyzed compromised websites were using outdated CMS software ^[12]. Although an automatic core update mechanism has been functioning in the WordPress platform since version 3.7, which significantly reduced the use of older versions, this problem still persists ^[34]. As of June 1, 2025, only 55.2% of WordPress websites had installed the then-latest version 6.8, which was released back in mid-April. By August 3, this figure grew to 69.1%, but this shows that a portion of systems continues using an outdated version even after a significant time has passed since the update’s release ^{[35, 36]}.

This trend reasonably suggests that administrators who fail to update the CMS core often do not sufficiently care about other critical components either—especially plugins, which, as statistics show, make up the vast majority of vulnerabilities in the WordPress ecosystem. A 2024 survey conducted by Melapress revealed that only 30% of users have automatic updates enabled on their websites ^[37]. However, these data should be evaluated contextually—some administrators consciously opt for manual update deployment to reduce the risk of potential compatibility issues or functional errors. In such cases, the choice, while motivated by caution, can contribute to heightened security risk in the long run.

It is important to emphasize that effective WordPress site protection is not limited to the security of the content management system itself—server software updates where the site is hosted also play a significant role. Updates to the server operating system, web server software (e.g., Apache, Nginx), database management systems, and other components are necessary to ensure protection against known vulnerabilities that could be exploited in cyber attacks. Insufficient server security management can become the weak link that allows attackers to bypass WordPress security measures and access site data or administrative tools. 

Reputation, Popularity, and Security Update Frequency of WordPress Component Developers

Due to its broad ecosystem, offering around 60,000 plugins in the official directory alone ^[38], WordPress faces multifaceted security challenges. Third-party components pose a particularly high risk, making their selection and critical evaluation a fundamental element of security assurance. When evaluating a component’s reliability, besides its direct functionality, it is crucial to consider factors such as the developer’s reputation, the software’s popularity, and the regularity of updates. In this context, developer reputation encompasses not only notoriety but also prior experience in resolving security incidents, response speed to vulnerability reports, and communication.

Research shows that there is a correlation between the usage scale of a WordPress component and its security level—less popular components more frequently exhibit security vulnerabilities. According to Wordfence’s 2024 report, 58% of all vulnerabilities identified during the year were found in software with fewer than 10,000 active installations, and 37% in software with fewer than 1,000 active installations ^[20].

This pattern can be explained by several factors. First, popular components feature greater maturity, as they are constantly scrutinized and evaluated by a large user community, which reports discovered issues more quickly. Second, the creators of such products usually have more financial and human resources at their disposal, allowing them to react promptly to security challenges and provide regular updates.

However, it is important to emphasize that the essential risk is determined not by the number of active installations, but by the lack of software maintenance. A regularly updated and maintained component, even with a small user base, can be more secure than a popular but abandoned or long-unupdated solution.

This issue is illustrated by a 2023 article published on the Patchstack blog, which reported 404 unpatched security flaws identified in 358 different WordPress plugins. The cybersecurity company noted that plugin developers were often unreachable or unresponsive to vulnerability reports. These flaws affected more than 1.6 million websites. Among the vulnerable plugins, two had over 100,000 active installations, and the oldest of them had not been updated for 13 years. In light of the situation, Patchstack informed the WordPress plugin review team—a volunteer group responsible for ensuring plugin security and quality—which removed over 70% of the vulnerable plugins from the official WordPress directory, significantly reducing the security risk to the community ^{[39, 40]}.

Removal of Unused and Outdated Plugins, Themes, or Other Components

The removal of unused WordPress plugins, themes, and other files is a vital cybersecurity practice. Although plugins or themes may be deactivated, their files physically remain on the server and can be accessed externally. In this way, outdated and unsupported components may contain security flaws and become a source of vulnerability ^{[41, 42]}. Therefore, it is necessary to regularly audit the system and completely remove unused components, rather than merely disabling them.

Additionally, various configuration leftovers, utility files, administration tools, etc., left on the server pose a significant security threat. Such files are often used during website development or testing, but leaving them in the production environment creates additional vulnerability risk. Cybercriminals continually use automated tools to search for such publicly accessible and often improperly protected files, which can become a potential attack vector ^{[43, 326]}.

One such example is Adminer—a database management tool which, although compact and convenient, can introduce extra risks if left on the server. The cybersecurity firm Sucuri recorded a widespread scanning campaign searching for publicly accessible Adminer files ^[45]. Once discovered, the tool can be exploited to gain database access by leveraging known vulnerabilities or conducting password guessing attacks. Thus, such tools must be removed immediately after use or their access restricted at the server level.

Furthermore, it is extremely important that website backups are not stored on the same server where the website operates. These copies often contain sensitive data, such as configuration files with database connection information. If these files become externally accessible, their contents can be exploited to bypass authentication mechanisms and gain unauthorized system access.

The importance of this is illustrated by the 2023 vulnerability disclosure regarding a security flaw in the Backup Migration plugin (versions up to 1.2.8 inclusive), which allowed unauthenticated users to access backup file locations and download them ^[46]. This case reveals potential risks associated with inadequately protected files and improper backup storage practices.

Unlicensed and Modified („Nulled”) Plugins or Themes

A prevalent practice in the WordPress ecosystem is the distribution of premium plugins and themes with their license verification mechanisms removed—so-called „nulled” versions, which pose both legal and security risks. 

While the WordPress platform and many of its components are licensed under the GNU General Public License (GPL), allowing free use and distribution of code, commercial plugins and themes sometimes apply mixed licensing practices where certain code or design elements remain legally protected. Therefore, the unauthorized use of such versions, especially if obtained from untrusted sources, can cause legal issues related to copyright infringement or illicit software distribution ^{[47, 48]}.

From a security perspective, embedded malware, hidden backdoors, or other modifications that allow compromising the site, stealing data, or exploiting server resources for malicious activity are frequently found in „nulled” components. Such plugins or themes also do not receive official security updates from vendors, leaving them vulnerable to newly discovered flaws ^[49]. 

Conducted studies thoroughly substantiate security risks of this nature. A 2020 Wordfence report states that over 200,000 infected WordPress sites were compromised by malware whose source was specifically modified „nulled” plugins or themes ^[50]. A 2018 Sucuri study presents similar conclusions, noting that such components often hide malicious code capable of granting access to third parties or executing unauthorized remote commands ^[51]. 

Additionally, a case described on the Sucuri blog details how downloading a random „nulled” theme resulted in discovering a disguised file containing harmful code. This code allowed the circumvention of security measures, the deactivation of popular protection plugins, and the transmission of confidential site data to remote servers. Although some malicious components can be detected using specialized tools, „nulled” versions mostly use significantly more obfuscated malware, making its identification via automated analysis tools difficult and not always effective ^[52]. 

Jetpack presented a similar case in its blog article, describing in detail how a „nulled” theme with embedded malicious code installed backdoor functionality, automatically created an administrator account, sent site data to a remote server, and allowed harmful files to be uploaded remotely to the site ^[53].

Beyond direct security threats, there is an important ethical aspect. Although the GPL license permits code distribution, legitimate developers of premium plugins and themes often fund their operations, product development, enhancement, and support through subscriptions. Using „nulled” versions undermines the developers’ business model, leaving their work and investments unrewarded ^[48]. This practice weakens the sustainability of the entire WordPress ecosystem and long-term innovation development.

Password Management and Applying Two-Factor Authentication

The security of logging into the WordPress administrative management interface is one of the most vital elements of overall site protection. To reduce the risk of unauthorized access, it is essential to use a strong and unique password for each user account. 

Traditionally, password strength was associated with its composition—recommending the use of uppercase and lowercase letters, numbers, and special characters. However, the latest guidelines from the National Institute of Standards and Technology (NIST) prioritize length, which is considered the primary indicator of password security. It is recommended to choose passwords no shorter than 15 characters or multi-word passphrases, which are easier to remember and less frequently force users to write them down or store them insecurely ^{[54, 55, 56]}. 

Studies show that overly strict composition requirements often encourage the creation of predictable patterns (e.g., „Password1!”), thereby weakening actual security. While such rules can be applied as an additional measure, it is important that they do not harm usability and do not encourage insecure behavioral models ^{[56, 57, 58, 59, 69]}. 

Moreover, ensuring password uniqueness is extremely crucial—it must not be used on other accounts or services to avoid risks associated with leaked login credentials ^[60]. 

Various specialized tools can be leveraged to evaluate password strength. For example, the „Bitwarden Password Strength Tester” tool analyzes password length, character variety, and randomness, providing an estimated evaluation of how long it might take to crack it using brute-force methods, where random character sequences and common combinations are systematically checked ^[61].

However, it is important to note that such tools assess only one specific aspect—resistance to systematic automated guessing. A password may be long and complex, but still be considered insecure if it is composed solely of known words, fits an easily predictable pattern, is reused across different accounts, or has already been included in publicly available leaked password databases.

This is illustrated by an example from a study conducted by Y. Chrysanthou. During the researcher’s test, a seemingly complex password, „Ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn1”, was cracked. Despite its length and the use of diverse characters, the password was successfully guessed within a few minutes because it was taken from a publicly accessible Wikipedia article and included in a specialized wordlist ^[220].

Modern password guessing methodologies are advanced. Various tools allow the application of hundreds or thousands of rules to words from a dictionary, e.g., appending numbers at the end, alternating upper and lower cases, or substituting characters („a” to „@”, „s” to „$”), etc. ^[219].

In reality, such attacks are mostly executed under specific conditions, when malicious actors have access to a leaked and encrypted password database. In such cases, passwords can be guessed locally, without limits on attempt counts, applying complex rules. Conversely, direct attempts to attack active login systems are significantly more constrained due to protection mechanisms and the physical ability to test a large number of passwords within an acceptable timeframe.

This example is provided to emphasize that password security depends on more than just complexity. Real risk remains when the same password has already been leaked in other services or matches known patterns. Therefore, password security must be evaluated comprehensively, not limited merely to resistance against automated guessing.

In such cases, it is useful to leverage other tools, for example, „Have I Been Pwned”, which allows checking whether a specific password has already been leaked ^[62]. Such tools rely on millions of real leaked data records and enable any user to evaluate their account’s vulnerability. Thus, when assessing password security, multiple different risk factors must be considered—and standard password strength evaluation tools should be applied only as a primary measure.

According to Cloudflare data, 76% of attempts to log in with leaked passwords on WordPress-based websites are successful. Even more concerning is that nearly half of such logins (48%) are executed by automated systems. These figures reveal the extent to which compromised accounts become targets for mass attacks aimed at leveraging previously leaked login credentials. The remaining 52% of successful logins are initiated by real users. This demonstrates the widespread habit of password reuse, which heightens the risk for accounts to be compromised ^[63].

The relevance of this threat is also revealed in the national context. The State Data Protection Inspectorate notes in its 2024 personal data security breach report that such cases have been recorded in Lithuania as well. The document states that credential stuffing cyber attacks were carried out, during which malicious actors, using leaked login data, attempted to log into user accounts on various websites ^[64]. This shows that real data leaks and their usage in attacks are not just theoretical risks—it confirms the necessity not only to use strong passwords but also to regularly verify their reliability.

However, even an extremely strong password does not guarantee absolute security. It can be compromised, for instance, due to a data leak on another platform, social engineering methods, or malware installed on the user’s device. For this reason, utilizing an additional layer of security—two-factor authentication (2FA)—is strongly recommended.

This method requires that, during login, the user not only enters the password but also additionally verifies their identity—most commonly by entering a temporary one-time code generated in a dedicated mobile app (e.g., Google Authenticator, Authy) or received via email. Even if the password were intercepted, attackers would be unable to gain access to the account without this second factor.

Properly implemented two-factor authentication significantly bolsters login security and is considered an effective measure in helping to protect accounts from unauthorized takeover and associated security incidents. This feature can be implemented in the WordPress platform by using dedicated plugins. Among the most widely used solutions are:

• „Two-Factor” (over 90K active installations, developer WordPress) ^[153];
• „WP 2FA – Two-Factor Authentication for WordPress” (over 70K active installations, developer MelaPress) ^[154];
• „Wordfence Login Security” (over 60K active installations, developer Defiant) ^[155];
• „Two Factor Authentication” (over 20K active installations, developer Team Updraft) ^[156];
• „miniOrange 2-factor Authentication (2FA with SMS, Email, Google Authenticator)” (over 10K active installations, developer miniOrange) ^[157].

Two-factor authentication functionality is also frequently integrated into comprehensive security plugins that cover a broader spectrum of protection measures. Such solutions do not limit themselves solely to enhancing login security—they often include additional features such as a web application firewall, malware detection, login monitoring, or other security enhancement functions. A list of some of these plugins will be presented in subsequent sections of the article.

Individual Access Control and Shared Account Risks

Individual access control is one of the core principles of cybersecurity—every user, especially those with administrative privileges, must be assigned a unique account. Despite this, the practice of using shared accounts remains prevalent in organizations, often based on the desire to optimize workflows or reduce administrative burden. However, this approach fundamentally contradicts information security principles and poses a significant risk.

First, a shared account eliminates the ability to accurately identify the actor behind an action, reducing accountability and complicating incident investigation. Second, in order to adapt the account for multiple users, the principle of least privilege is frequently violated—such accounts are granted excessive permissions, increasing the likelihood of potential breaches. Third, sharing passwords among employees heightens the risk of access credentials being accidentally or intentionally transferred to unauthorized individuals ^{[65, 66, 67]}.

Studies from various sources indicate that user account and password sharing practices remain common in organizations. For instance, according to a 2019 SurveyMonkey poll, 34% of respondents indicated they had shared accounts or login credentials with colleagues, and 42% of this group did so to facilitate collaboration ^[70]. Similar trends were revealed by a 2021 Beyond Identity study, where 41.7% of employees admitted to having shared their work accounts or passwords at least once ^[71].

Access control must be perceived as an ongoing process involving the review of user accounts, adjustment according to their functions, and timely removal of unnecessary accounts. Upon an employee’s departure from the organization or when an account becomes inactive, access must be immediately suspended or revoked to prevent potential security breaches ^[68].

Nevertheless, empirical studies show that organizations often fail to adequately implement account management and access restriction policies. According to 2024 Wing Security research data, 63% of organizations still had not restricted former employees’ access to certain systems or data ^[72].

Based on the results of a 2023 PasswordManager survey, almost half (47%) of respondents admitted to having logged into a former employer’s systems at least once using previously held access credentials. Mostly, access persisted due to passwords not being changed after the employee’s departure (58%) or access being granted to individuals still working in the organization (44%). Moreover, 10% of respondents stated they consciously used former organizational access credentials aiming for intentional impact capable of causing harm ^[73].

The risk posed by shared account usage is also illustrated by the analysis of an information security incident conducted by the company Remitalis. During the investigation, it was determined that a shared account was used to administer an e-commerce platform, through which an employee intentionally installed malware. This software allowed third parties to unlawfully access customer personal data, which was subsequently leaked to the dark web and publicly disclosed. The incident caused the organization financial losses and long-term reputational damage.

Such cases emphasize that account management is not merely a formal procedural action, but a critical information security practice. Although the risk associated with shared or unsupervised accounts is sometimes viewed as unlikely or theoretical, data proves that these dangers can result in substantial consequences. Therefore, it is imperative to ensure consistent account management throughout their entire lifecycle—from creation to timely removal.

Additionally, the risks related to email addresses assigned to administrative accounts must be evaluated. Shared mailboxes, such as „info@”, „sales@”, or similar, accessed by multiple employees, can be used to initiate password resets and gain privileged access to the system. The situation is further aggravated because these addresses are published publicly, such as in website contact sections, thus becoming easy targets for cyber actors capable of exploiting email addresses to conduct phishing, credential guessing, or other malicious attacks ^{[74, 75, 76, 77]}.

To mitigate these risks, organizations should ensure that only personal, user-specific email addresses are used in administrative accounts. It is also recommended to restrict automatic password recovery functionality or supplement it with additional authentication measures. For instance, in the WordPress CMS, the password reset function can be disabled using a filter ^[78]: 

add_filter( 'allow_password_reset', '__return_false' );

Security Plugins

Comprehensive WordPress security plugins are specialized tools designed for the all-around protection of a website from cyber threats. Unlike isolated tools, these plugins combine several interrelated and coordinated protection features, thus ensuring a consistent security level. Depending on the solution, comprehensive plugins typically integrate the following core areas:

1) One of the essential components of comprehensive security plugins is the web application firewall (WAF), whose main function is to analyze and filter incoming traffic to the site, blocking potentially harmful requests in the early stages of an attack. Such protection reduces the probability of vulnerability exploitation and ensures defense against the most common cyber attacks, including unauthorized database query execution attempts, malicious code injection, forbidden file uploads, attempts to access sensitive server data or configuration files, and other similar threats ^{[79, 80]}.

Based on their operational architecture, web application firewalls can be divided into several categories. One of the widely applied types is cloud-based WAFs, which operate as reverse proxies through which all incoming site traffic is routed. Such systems, like Cloudflare, Sucuri Security, or MalCare, perform request analysis and blocking within the service provider’s infrastructure, rejecting malicious traffic even before it reaches the site server. This architecture not only mitigates security risk but also allows for more targeted server resource management ^{[81, 82, 83, 84, 85]}.

Another significant firewall category is application-level WAFs, which operate directly within the site’s software environment and are frequently installed as CMS plugins, such as the widely used Wordfence Security or Solid Security on the WordPress platform. These firewalls filter requests before executing software code related to site themes or plugins, enabling the application of specialized security rule sets tailored to the specific vulnerabilities of the WordPress system, thereby strengthening the effectiveness of the protection ^{[85, 86, 87]}.

Additionally, it is worth noting that one effective strategy is the application of a hybrid model, combining cloud-based firewalls, such as Cloudflare, which act as a first line of defense blocking malicious requests and denial of service attacks, with application-level firewalls or other WordPress-oriented security solutions. The latter mechanisms ensure a more detailed analysis of requests and allow for protection against specific CMS vulnerabilities. This approach establishes a multi-layered defense model that reduces the impact of cyber threats at both the infrastructure and software levels and diminishes reliance on a single protection mechanism ^{[88, 89, 90, 91, 92, 93, 94]}.

2) Proactive vulnerability management is an automated process designed to systematically assess the security of site components by checking the versions of the WordPress core, themes, and plugins to identify potential security flaws. Modern security plugins compare scan results with centralized, continually updated vulnerability databases, such as the Patchstack Vulnerability Database, Wordfence Intelligence, or WPScan Vulnerability Database. These databases compile information on known vulnerabilities within the WordPress ecosystem, presenting their classification, risk level, and technical descriptions ^{[95, 96, 97]}. 

It is important to note that most of these vulnerabilities stem from outdated or unmaintained components, which become easy targets for attacks. Thus, the vulnerability scanning function serves a crucial preventive role—it allows timely identification of critical flaws and the implementation of protective measures, such as updating or temporarily disabling insecure components, before they turn into real attack vectors.

3) Malicious code detection and file integrity monitoring are vital WordPress site security components ensuring early threat identification and system integrity maintenance. Malicious code detection mechanisms generally rely on the analysis of known malware signatures or code fragments, enabling the identification of injected malicious content. Meanwhile, file integrity monitoring is based on comparing the state of site files with benchmark WordPress core, theme, and plugin versions or previous trusted and secure records. Such systematic oversight enables prompt detection of unauthorized changes and alerts the administrator, providing the opportunity to react to potential security incidents in a timely fashion ^{[98, 99, 100]}. 

4) Comprehensive security plugins integrate advanced authentication measures designed to grant access to the administration environment strictly to authorized users. These measures encompass limiting the number of login attempts, IP address filtering, applying two-factor authentication (2FA), and implementing automated alert mechanisms in response to unusual logins. Beyond primary authentication control, security plugins frequently provide additional protective features aimed at minimizing the risk of potential security breaches, such as hiding the default administrator login address or restricting username disclosure, thereby reducing the probability of authentication data leakage ^{[101, 102, 103]}. The combination of these measures builds a multi-layered authentication defense that ensures reliable access control to the administration environment.

5) The audit log functionality in comprehensive security plugins provides the capability to systematically record various site events, including successful and failed logins, user account creation, password changes, plugin or theme installations, configuration alterations, and other significant system events. Detailed event logging forms the foundation for security incident analysis, allows the identification of potential breaches, and evaluates their impact on the system. Furthermore, integrated alerting mechanisms notify administrators of critical events that may signal disruptions or threats, thereby enhancing proactive security management ^[104].

6) Security plugins frequently integrate supplementary preventive measures aimed at fortifying site protection against various cyber threats. Such measures can include disabling file editing via the administration interface, securing critical configuration files like `wp-config.php` or `.htaccess` against public access, hiding WordPress version information, altering the default database table prefix „wp_”, deploying mechanisms to prevent automated attacks, or other similar security enhancements. By integrating these preventive measures, they become an essential security architecture component ensuring system reliability and resilience against cyber threats ^{[102, 103, 105, 106, 107, 108, 109]}.

These reviewed functional areas represent the core capabilities of WordPress comprehensive security plugins, although their spectrum can vary and depends on the specific chosen solution. Some may prioritize proactive vulnerability management, while others emphasize real-time protection through a firewall or malicious code detection ^[110]. When evaluating such solutions, it is essential to consider whether their offered features align with security requirements and their compatibility with existing infrastructure and other utilized tools.

Below is a list of WordPress security plugins reflecting widely used solutions in this ecosystem:

• „Wordfence Security – Firewall, Malware Scan, and Login Security” (over 5M active installations, developer Defiant) ^[111];
• „Jetpack – WP Security, Backup, Speed, & Growth” (over 4M active installations, developer Automattic) ^[112];
• „Really Simple Security – Simple and Performant Security” (over 4M active installations, developer Really Simple Plugins) ^[113];
• „All-In-One Security (AIOS) – Security and Firewall” (over 1M active installations, developer TeamUpdraft) ^[114];
• „Security Optimizer – The All-In-One Protection Plugin” (over 900K active installations, developer SiteGround) ^[115];
• „Solid Security – Password, Two Factor Authentication, and Brute Force Protection” (over 800K active installations, developer SolidWP) ^[116];
• „Sucuri Security – Auditing, Malware Scanner and Security Hardening” (over 700K active installations, developer Sucuri) ^[117];
• „MalCare WordPress Security Plugin – Malware Scanner, Cleaner, Security Firewall” (over 200K active installations, developer MalCare) ^[118];
• „NinjaFirewall (WP Edition) – Advanced Security Plugin and Firewall” (over 100K active installations, developer NinTechNet) ^[119];
• „Defender Security – Malware Scanner, Login Security & Firewall” (over 90K active installations, developer WPMU DEV) ^[120];
• „Patchstack – WordPress & Plugins Security” (over 30K active installations, developer Patchstack) ^[121];
• „Login Security, FireWall, Malware removal by CleanTalk” (over 30K active installations, developer CleanTalk) ^[122];
• „BulletProof Security” (over 30K active installations, developer AITpro) ^[123].

It is also important to consider the operational limitations of security plugins: while they are an integral part of a WordPress site protection strategy, their functionality cannot ensure absolute protection against cyber threats. Cybercriminals continuously develop tools to bypass or neutralize these solutions. Cases have been documented where specialized malware identifies popular security plugins and systematically disables or disrupts their operation. To maintain illicit access and deceive the site administrator, attackers employ more sophisticated deception techniques—for instance, simulating regular plugin operation in the dashboard, even though the actual protection features have already been deactivated ^{[124, 125, 126, 127]}.

Moreover, the risk stems not only from external attacks—vulnerabilities can be discovered within the security plugins themselves. While such cases are not widespread, they validate that software vulnerabilities, including within security plugins, are an inevitable aspect of a dynamic cybersecurity ecosystem. Below are several examples of vulnerabilities that have affected the WordPress ecosystem over the past years:

• In 2025, a critical security flaw was identified in the „Melapress Login Security” plugin (versions 2.1.0–2.1.1). It allowed unauthenticated attackers possessing a certain user metadata value (e.g., user ID or email) to bypass authentication mechanisms ^{[128, 129]}.
• In 2025, a critical security flaw was identified in the „Security & Malware scan by CleanTalk” plugin (versions up to 2.149 inclusive), which allowed unauthenticated attackers to upload malicious files ^[130].
• In 2024, a critical security flaw was discovered in the „Really Simple Security” plugin (versions 9.0.0–9.1.1.1), affecting more than 4 million WordPress sites and allowing unauthorized users to bypass authentication mechanisms ^[131].
• In 2023, a security flaw was discovered in the „MalCare” security plugin (versions up to 5.09 inclusive) associated with storing the API authentication key in the database in clear text format. Given additional vulnerable site features, a hacker obtaining this key could impersonate the legitimate MalCare service and take over site control ^[132].
• In 2022, a security flaw was detected in the „Jetpack” plugin (versions up to 11.3.1 inclusive) allowing firewall protection bypass due to inaccurate user IP address determination. This flaw provided an opportunity for attackers to spoof their IP address ^[133].
• In 2022, flaws detected in the „All-In-One Security” plugin (versions 5.0.0–5.0.7) allowed bypassing two-factor authentication (2FA) and configured IP address restrictions on the login page ^{[134, 135, 136]}.

Ultimately, it is essential to critically evaluate the functionality offered by comprehensive security plugins. Malware detection mechanisms are criticized by security researcher C. Alkan, whose 2023 study reveals that both local and remote WordPress scanners suffer from fundamental limitations. Local scanners operate at the same software level as the malware, allowing the malware to attempt manipulating their execution—disabling them, altering their functionality, or evading detection by adding itself to exclusion lists. Furthermore, in some instances, they fail to identify dynamically generated or one-time malicious code that deletes itself immediately after execution, leaving no traces. Analogous problems arise when using remote solutions: although analysis is performed on external servers, data collection relies on a local plugin operating in the same environment as the malware. This creates opportunities to manipulate or spoof transmitted information, thus projecting a false representation of site security ^{[137, 138]}. 

The function of detecting vulnerable components was detailed in a 2021 empirical study by Murphy et al., which evaluated the capability of eleven popular security plugins to identify 51 plugins with known flaws. The study revealed that the effectiveness of this function varies: while top-performing plugins, such as SecuPress (detected 43) and Wordfence (detected 42), identified the majority of vulnerabilities, others, such as Security Ninja (16) or Titan Anti-spam & Security (11), detected significantly fewer. It is important to note that over half of the tested plugins did not offer this feature at all in their free versions ^[139]. Although the study was conducted a few years ago, its conclusions remain relevant and support the assertion that relying solely on automated tools is risky. Consequently, site administrators face the necessity of independently staying informed about the security of the components they use and critically assessing their potential impact on the system.

These analyzed aspects suggest that the use of comprehensive security plugins can, in some cases, instill a false sense of security. Effective website protection must be grounded not only on static trust in installed tools, but on a holistic approach encompassing risk assessment, continuous monitoring, and the ability to flexibly adapt defense mechanisms to evolving threats. Furthermore, it is crucial to critically evaluate the reliability of the security plugin itself and supplement it with independent protection measures not necessarily directly tied to the WordPress environment, such as external firewalls or server-level security measures. 

Nevertheless, it must be acknowledged that security solution developers constantly strive to adapt to the changing nature of cyber threats. For instance, Wordfence continuously improves its solutions based on a broad vulnerability database and a real-time threat defense feed. The threat intelligence team systematically investigates real incidents, analyzing malware samples, identifying novel attack techniques, and integrating them into protection mechanisms. Similar research activity characterizes other organizations: Sucuri, Patchstack, and Automattic (Jetpack, WPScan) also constantly collect, analyze, and systematize data concerning identified threats, vulnerabilities, and employed attack methodologies ^{[22, 140, 141, 142, 143, 144, 145]}. This continuous process of analysis, updating, and adaptation enables security tools to effectively neutralize both widespread threats and those specific to the WordPress ecosystem, therefore remaining a vital part of active website defense.

Additionally, when analyzing the operation of comprehensive plugins, it is useful to note that due to their functionality, they may sometimes negatively impact website performance. This is most frequently manifested during intensive processes, such as malware scanning, local firewall operation, or other real-time protection mechanisms constantly analyzing data traffic. This impact is especially pronounced in shared hosting environments and high-volume sites where resource demand is substantially higher.

For example, some users have indicated that using Wordfence—one of the most popular security plugins in the WordPress ecosystem—can increase page load times and slow down certain site functions, particularly when malware scanning processes are running or significant visitor traffic is being processed ^{[146, 147, 148]}. Nevertheless, these performance shifts are not necessarily an obstacle to utilizing such solutions—in most cases, they can be managed by ensuring adequate server resources, optimizing site structure, and reducing the load of unnecessary processes ^{[149, 150, 151]}. Alternatively, one can choose other security solutions, such as Sucuri Security or MalCare, whose firewall and malware detection are executed on external, cloud-based servers, thereby reducing direct load on the site infrastructure.

Login Rate Limiting

The scale of automated brute-force attacks and credential stuffing attacks is revealed by Wordfence’s 2024 statistics: over 55 billion attempts to log into WordPress sites were recorded and blocked throughout the year, executed from nearly 136 million unique IP addresses ^[20]. This statistic exposes not only the massive scale of such attacks but also the necessity of applying supplementary authentication protection measures.

One of the most frequently used measures is rate limiting. The core of this method is setting a threshold on how many failed logins can be performed within a specific time interval (e.g., ten minutes). Once this limit is exceeded, the system temporarily blocks logins from a specific IP address or restricts access to a user account. Such a mechanism can reduce the efficacy of automated attacks and limit the additional server load caused by intensive and repeated login requests.

However, this method is not without its flaws. Rate limiting can be turned against the system itself—for instance, by initiating numerous failed logins, it is possible to cause a denial of service, temporarily blocking legitimate users’ access. Cases where attacks are executed from within the organization’s internal network are also problematic: in this scenario, the utilized IP address may be considered trusted, thus exemptions apply to it, allowing unlimited attempts. Conversely, if an external IP address is not considered trusted, it can be leveraged for a targeted attack aiming to disrupt the entire organization’s access to the system.

Although the vast majority of automated attacks against systems like WordPress are random and broad in scale, the possibility of targeted and internal attacks must also be evaluated. A threat can originate not only from the outside but from within—via employees, partners, or service providers with network access. Therefore, security strategies must encompass both external and internal threat management.

The effectiveness of authentication limiting measures is also diminished by distributed attacks employing proxy server networks. Login requests are routed through thousands of varying IP addresses, thus each may individually stay below established thresholds and evade blocking. The scale of such attacks is further magnified by commercial services offering access to a broad and continually updated network of IP addresses spanning millions of unique addresses from various global regions ^[158].

Despite these challenges, rate limiting remains a crucial supplementary protection measure. It effectively guards against rudimentary mass attacks executed from individual or small sets of IP addresses and elevates their execution costs. Consequently, the authentication rate limiting mechanism contributes significantly to overall system resilience. However, for enhanced security, rate limiting can be combined with other protective measures, such as device fingerprinting analysis, which helps identify recurrent attack sources, IP address reputation analysis, which allows blocking requests from known malicious networks, and the integration of visual or logical reasoning tasks.

Authentication limiting can be implemented using specialized WordPress plugins designed for login attempt control and protection against automated attacks. Among the most frequently used solutions are:

• „Limit Login Attempts Reloaded – Login Security, Brute Force Protection, Firewall” (over 2M active installations, developer WPChef) ^[159];
• „Loginizer” (over 1M active installations, developer Softaculous) ^[160];
• „Login Lockdown & Protection” (over 100K active installations, developer WebFactory) ^[161];
• „WP fail2ban – Advanced Security” (over 100K active installations, developer invisnet) ^[162].

Additional protection against automated requests is provided by CAPTCHA technologies. Below are several widely used solutions in this field:

• „Advanced Google reCAPTCHA” (over 200K active installations, developer WebFactory), which integrates Google reCAPTCHA into login, registration, password recovery, and comment forms ^[163];
• „hCaptcha for WP” (over 70K active installations, developer hcaptcha), a privacy-focused alternative to Google reCAPTCHA, helping protect login, registration, password recovery, comments, and other forms from automated bots and abuse ^[164].

Authentication security features are frequently integrated into the comprehensive security plugins that were discussed earlier in this article. When selecting a specific authentication security plugin, it is vital to evaluate its functionality, compatibility with the used WordPress version, and other measures operating on the site. Some plugins offer a broad spectrum of protection features—from login limit rates to firewalls and malicious activity monitoring. Nonetheless, due to their complexity, they might burden the system or cause compatibility issues. Therefore, the decision should be grounded on specific site needs: whether only basic login control is required or an extended security solution.

Restricting Login Access via IP Addresses

One widely applied authentication strengthening method is access restriction based on an IP address allowlist (whitelist). In this scenario, access to the administrative environment is granted only to pre-approved IP addresses, while all other attempts are automatically rejected. This establishes an additional layer of access control and can remain effective even in cases where unauthorized individuals acquire valid authentication credentials.

This method is most suitable for organizations utilizing static (unchanging) IP addresses, as it allows reliable identification of access sources. However, in practice, situations are often encountered where user IP addresses change constantly—this is typical of remote work, mobile internet, or ISP networks where addresses are assigned dynamically. In such instances, IP address rotation can lead to access disruptions if new addresses are not added to the allowlist in a timely manner ^[165].

To balance security and access flexibility, organizations frequently deploy hybrid solutions—for example, requiring authentication via a Virtual Private Network (VPN) whose egress IP address is fixed and known. In such a setup, a change in the user’s IP address has no direct impact on the access control policy ^[166].

Nevertheless, an IP address allowlist has limited efficacy. This measure does not protect against internal threats: if an unauthorized person (e.g., an employee or service provider) gains network access, their IP address may falsely be deemed trusted. Moreover, the method does not defend against attacks initiated from compromised devices inside the organization. For this reason, IP-based control should be employed only as an auxiliary defense layer within a broader security strategy.

If utilizing an IP address allowlist is impossible due to technical or organizational constraints, geographic filtering can be an alternative. In this case, access to the administrative environment is restricted based on IP address origin—for example, allowing logins only from a specific country. This method is particularly relevant when access to the CMS is required only from one geographic location.

Geographic filtering enables restricting access from untrusted external sources, including those leveraging anonymization services (e.g., VPNs, the TOR network, or proxy server infrastructure). Although some of these services may operate within the permitted region and enable restriction circumvention, this measure is nevertheless especially potent as a preventive filter against automated large-scale attacks ^{[167, 168, 169, 179]}.

IP address filtering can be implemented at various information system levels, depending on its architecture and administration environment. One commonly applied method is server-level restriction, utilizing web server configurations like Apache or Nginx.

For example, in Apache server configuration, IP-based access control can be realized in two primary ways depending on the version used ^[170]:

Apache 2.2

Order Deny,Allow
Deny from all
Allow from 123.123.123.123
Allow from 111.111.111.111

Apache 2.4 and newer versions

<RequireAny>
    Require ip 123.123.123.123
    Require ip 111.111.111.111
</RequireAny>

These configuration snippets can be applied both in main server configuration files (e.g., „httpd.conf” or virtual host definitions) and in the „.htaccess” file, provided the server permits this feature (the AllowOverride directive is not disabled). However, for performance and security reasons, it is recommended to utilize main configuration files whenever possible ^[171].

Another widely adopted IP filtering method is access restriction at the network perimeter level, leveraging external security solutions such as Cloudflare. Using this platform, IP-based access control is implemented via custom-configured firewall rules. This allows traffic filtering before it even reaches internal infrastructure. In the administration interface, one can specify a distinct IP address, an address range, or a geographic location to which corresponding allow or block rules are applied ^[172]. This method is particularly useful for reducing server load and repelling automated attacks as well as attempts to bypass local access control.

IP restriction can also be implemented within the WordPress CMS itself via dedicated plugins. This capability is especially relevant in environments where users lack direct access to server or network-level security configurations—for instance, when using shared hosting services. In such cases, plugins offer the flexibility to manage access limits through the administration interface, making them suitable for both advanced and less technically experienced users.

As discussed in the previous section, many authentication protection functions are integrated into comprehensive security plugins that simultaneously provide various protective measures. These solutions enable centralized management of critical security aspects—from access control and known threat monitoring to automated response against suspicious activity.

Server-Level Password Authentication

An additional measure designed to reinforce WordPress administrative section security is implementing password authentication at the server level using „HTTP Basic Authentication”. This method is configured in the server settings, for example, in an Apache environment, utilizing „.htaccess” and „.htpasswd” files. Usually, this protection is applied to the „wp-admin” directory, and authentication occurs prior to the execution of the main site software code, thus minimizing the entry of unwanted traffic into the WordPress system ^[173].

In WordPress developer administration and security documentation, „HTTP Basic Authentication” is identified as an extra security layer designed to restrict unauthorized access ^[174]. Nonetheless, this form of authentication should not be applied as a sole measure, but rather as a complementary solution alongside other security practices. 

To reduce risk, it is advised to store the authentication configuration files outside the site’s root directory, thus restricting their direct accessibility via the browser. Additionally, it is essential to ensure that authentication takes place using the HTTPS protocol, which encrypts all data transmission and safeguards login credentials against interception, thereby reinforcing overall system security ^{[173, 175, 178]}.

Compatibility issues must also be considered. Improperly implementing server-level authentication can disrupt the functionality of certain plugins or themes that require unhindered access to specific administration-side files. Therefore, it is recommended to carefully evaluate the site’s operational characteristics and, if necessary, foresee necessary exception applications ^{[176, 177]}.

If the site lacks registered users or public login functions, it is advised to additionally protect the „wp-login.php” file. This way, the login form becomes inaccessible without the extra password.

When utilizing the Apache web server, „HTTP Basic Authentication” can be implemented in the „.htaccess” file by specifying protection rules. The example below illustrates how to configure an additional password requirement for both the „wp-login.php” file and the „wp-admin” directory. 

„.htaccess” file configuration in the root directory

<Files "wp-login.php">
    AuthName "WordPress login protection"
    AuthType Basic
    AuthUserFile "/full/path/to/.htpasswd"
    Require valid-user
</Files>

„.htaccess” file configuration in the „/wp-admin” directory

AuthName "WordPress administration zone"
AuthType Basic
AuthUserFile "/full/path/to/.htpasswd"
Require valid-user

# Allow access to the admin-ajax.php file
<Files "admin-ajax.php">
    Require all granted
</Files>

# Allow access to the admin-post.php file
<Files "admin-post.php">
    Require all granted
</Files>

Password data is stored in a separate „.htpasswd” file, which can be generated through various means. On Linux systems, the official Apache utility „htpasswd” is most frequently used, allowing the creation and updating of user authentication data files. For instance, the command

htpasswd -c /path/to/.htpasswd username

creates a new file and prompts for a password, which is encrypted using secure algorithms. This ensures data security and compatibility with the Apache server’s authentication mechanism. For users lacking direct command-line access, public password generation tools are available that output a „username:encoded_password” format string, suitable for pasting into the „.htpasswd” file.

Changing the Default Administrative Login URL

By default configuration, the WordPress login form is publicly accessible using standard paths like „/wp-login.php” or „/wp-admin”. Because these addresses are easily guessed, they frequently become targets for automated attacks and are constantly probed to uncover potential vulnerabilities.

A comprehensive 2025 WordPress security analysis by ServerAvatar revealed that one of the most significant risks is a publicly accessible and improperly secured administrator login interface. The study, encompassing nearly 70,000 sites, revealed that 62.77% use an unchanged default login URL, which substantially heightens the likelihood of becoming a target for automated attacks ^[180].

Considering this risk, it is recommended to change the default address to a non-standard, harder-to-guess one (e.g., „/secret-login”), thereby reducing the volume of automated requests and complicating the discovery of the login form. Nonetheless, this measure should be viewed merely as an auxiliary layer of protection that must be combined with other security practices.

The method of hiding the administrator login interface relies fundamentally on the „security by obscurity” concept—that is, obscuring access points or other system information, hoping that a potential attacker or someone probing for security gaps will not notice them. While hiding access points helps diminish automated request traffic in some cases, it does not guarantee total immunity to organized, targeted attacks where hackers might use more sophisticated information retrieval methods or leaked data ^{[181, 182]}. Furthermore, changing the login URL can cause compatibility issues with some plugins or systemic integrations; therefore, potential consequences on the overall site infrastructure operation must be evaluated ^[183].

Despite the aforementioned limitations, practical experience indicates that altering the login URL can be an effective supplementary security component, particularly in mitigating the intensity of automated attacks. This solution should be implemented as one of multiple measures forming the foundation of a layered security strategy. The method must be combined with other security measures, such as IP-based access restriction, login attempt limits, two-factor authentication, and regular deployment of security updates.

Dedicated plugins are typically utilized to change the login page URL. One widely used solution is the „WPS Hide Login” plugin (over 1 million active installations, developer Remy Perona) ^[184]. This tool enables easily setting an alternative login path without altering core system files. A similar function is also frequently integrated into comprehensive security plugins. Before deploying any solution, a thorough evaluation of existing protective measures and their mutual compatibility is advised.

Changing the Administrator Username

One frequent yet flawed WordPress deployment practice from a security standpoint is creating the administrator account using the username „admin”. This username frequently becomes the primary target for automated login attacks. Since both a username and password are required for successful authentication, employing a publicly known and easily guessable username eliminates one protection layer, thus amplifying the success probability of potential attacks.

Although merely hiding information, as discussed earlier in this article, is not deemed a sufficient security strategy, WordPress documentation notes that changing the username to a more unique one can still significantly lower the likelihood of automated login attacks ^[174]. The OWASP guidelines for WordPress security assurance present similar recommendations. They emphasize not only the significance of the username, but also that the default administrator account is often assigned the identification number „1”. This highly predictable value can be exploited for various attack types—for instance, determining the login name or constructing malicious SQL queries ^[185].

A massive automated attack executed in 2013 vividly demonstrated the threat posed by default administrator credentials. A botnet comprising over 90,000 infected devices was utilized for this attack, systematically attempting to log into WordPress sites using the name „admin” paired with common password combinations. As WordPress founder M. Mullenweg emphasized, due to the broad spectrum of IP addresses, standard protection techniques like rate-limiting logins or blocking the botnet became virtually ineffective. Though since 2010 WordPress installation provides the option to choose a unique username, this incident revealed that using the standard name „admin” remains a prevalent security vulnerability, particularly if administrators fail to implement even rudimentary protective measures ^{[186, 187, 188]}.

Based on more recent data, this problem remains relevant in the modern context. Between January and September 2023, over 1.8 million leaked administrator account passwords were analyzed by Outpost24’s KrakenLabs threat intelligence team. The study results revealed that the most frequently occurring password was „admin”—accounting for over 40,000 records. This not only indicates weak passwords but also reasonably suggests that standard or easily guessable usernames might be used concurrently ^[189]. 

Moreover, the username „admin” can present a risk indirectly—even without authentication mechanism breaches. One example is the ThemeGrill Demo Importer plugin security vulnerability (versions 1.3.4–1.6.1), which permitted unauthenticated users to initiate a full database reset to default parameters. At that time, the plugin was installed on more than 200,000 active WordPress sites. If an account with the name „admin” existed on such a site, the plugin would automatically log into it and grant full administrative privileges ^[190]. This case illustrates how the presence of a widely known username can contribute to system compromise even without direct access to a login form.

Changing the username can be executed using dedicated security plugins, as mentioned in previous chapters, or by making manual alterations within the database. In the latter case, an SQL query updating the value in the „wp_users” table can be executed ^[191]:

UPDATE `wp_users` SET user_login = 'unique_administrator_name' WHERE user_login = 'admin';

Prior to making any direct database modifications, it is imperative to create a website backup to guarantee data recovery in the event of disruptions. It is also important that these actions are carried out solely by a specialist possessing the requisite technical competence—this helps prevent data integrity violations or other malfunctions.

As previously mentioned, the default administrator account identification number (ID), typically the value „1”, introduces additional risk. This value is pointed out in OWASP guidelines as a supplementary potential attack vector ^[185]. However, changing the user ID value in the WordPress system is more complex than amending the username. This value serves as a primary key within the system, linking the user to all associated information—posts, comments, metadata, and other database elements. Careless modification of this identifier can cause relational table link breakages, resulting in functional website issues or even data loss ^{[192, 193]}. For this reason, altering the user ID should be done responsibly and with a clear understanding of database structure and potential consequences.

Nonetheless, it’s vital to understand that simply changing a username or ID is insufficient—these measures are only effective when paired with supplementary steps that block username disclosure, which is discussed more extensively in the next section.

Username Enumeration Prevention

The possibility of user enumeration in content management systems like WordPress poses an information security risk. This technique allows for the identification of valid usernames by utilizing their identification numbers (user ID), which, even if unique or difficult to guess, can be discovered. For instance, the standardized query „/?author=ID” in many WordPress systems can reveal the username associated with a specific identifier. Such information disclosure sets the stage for further, targeted cyber actions and is considered a significant security flaw ^{[194, 195]}.

Possessing a valid username, an attacker can initiate password guessing attacks, trying out various password combinations. In this case, one of the two authentication pieces is already known, significantly reducing attack complexity and heightening its success probability.

Beyond technical threats, user enumeration enables social engineering attacks, such as targeted phishing, wherein attackers, utilizing known usernames, dispatch personalized and authentic-looking requests aimed at coercing additional information or login credentials. This sort of attack can target both system administrators and other registered users, boasting high efficacy as it exploits the human factor of trust.

To diminish the risk of username disclosure, specialized plugins can be employed. One of them is „Stop User Enumeration” (over 50,000 installs, developer Fullworks). This tool automatically blocks user information retrieval queries executed via standard URLs, the REST API interface, the oEmbed mechanism, and the sitemap. Moreover, the plugin permits logging suspicious IP addresses and, if needed, integrates with the „fail2ban” system, thus providing the ability to apply extra security measures at the server level ^[196].

An alternative approach is manual system configuration at the server or application level, permitting exact definition of protection rules and eliminating dependency on third-party code. This approach grants greater control and enables the implementation of custom-tailored security solutions. Key prevention actions involve blocking the following attack vectors ^{[197, 198, 199]}:

• Login and password recovery forms. It is recommended to modify system responses to failed login attempts so they are neutral and divulge no information regarding whether the error is username- or password-related. For instance, instead of specific error messages, a generic text like „Invalid details entered” should be used. Analogously, password reset forms should invariably return a uniform response regardless of the validity of the entered data, aiming to prevent extra information leakage about registered users.
• Author archives. To prevent revealing information about authors, queries to author archives (e.g., „/?author=ID”) can be blocked or redirected to a general site page.
• REST API endpoints. The ability to access endpoints that might display author data (e.g., „/wp-json/wp/v2/users”, „/wp-json/wp/v2/posts”, „/wp-json/oembed/1.0/embed?url=”) should be restricted solely to authorized users or ensured that this data is not publicly accessible.
• XML-RPC interface. Functions accessible via „xmlrpc.php”, such as „wp.getAuthors”, can disclose user login names and other sensitive information. If this interface’s functionality is non-essential, it is advised to limit or entirely block access to it at the server level.
• Template (theme) files. During code auditing, it is recommended to remove functions (e.g., „the_author()”) that publicly display author login names.
• RSS feeds. It is practical to modify the RSS feed generation function so that a public pseudonym is provided in the „dc:creator” tag, or the tag is not generated at all.
• Sitemaps and structured data. To limit author information disclosure, it is advised to check that automatically generated sitemaps and JSON-LD formatted structured data omit author names or links to their archive pages.

In summary, the listed user identification vectors represent only a fraction of potential risk points. Since these mechanisms and their impact are continually changing, and cyber threats evolve, the emergence of new vulnerabilities is inevitable. To ensure system resilience against current threats, one must consistently conduct monitoring, log and analyze newly identified vulnerabilities. Only such persistent and focused oversight allows the timely adaptation of applied protection measures and the maintenance of their effectiveness in a dynamic cyber environment.

Session Management 

To decrease the risk of unauthorized access to user accounts, automated logout mechanisms must be deployed that trigger after a set period of user inactivity. If a user remains idle for a prolonged period, the system must automatically terminate the active session. This solution significantly lowers the probability of unauthorized account access—especially in instances where a device is left unattended or when bad actors employ session hijacking methods ^{[200, 201, 202]}.

In many web systems, including WordPress, user authentication relies on session IDs typically stored in browser cookies. If such a cookie is intercepted—for example, via malware, insecure public Wi-Fi networks, or site security vulnerabilities—a malicious individual can gain access to the user’s account without additional authentication ^{[203, 204, 205, 206, 207]}.

According to a 2023 broad-scale analysis of WordPress site hacks conducted by WeWatchYourWebsite, stolen session cookies constitute a significant attack vector, responsible for roughly 60% of successful hacks. The authors of the study note that session hijacking attacks boast a high success rate because the WordPress core lacks built-in protection mechanisms to neutralize this threat. Such attacks are extremely hazardous as they bypass standard authentication safeguards, including two-factor authentication. Cookies are mostly used within the first 48 hours of interception, but if the „Remember me” feature is checked, their validity can extend up to 14 days, thus expanding the hackers’ window of opportunity ^[208]. 

It is important to note that while the 60% figure underscores the substantial significance of session cookie interception, it is debated within the security expert community. For instance, cybersecurity firm MalCare critically evaluates these claims, holding the position that exploiting known vulnerabilities remains the principal cause of hacks ^[209]. The authors of the WeWatchYourWebsite study note that the session hijacking trend might be significantly altered during instances of mass exploitation of newly discovered critical vulnerabilities ^[208]. Due to these fluctuations, although the exact percentage breakdown might shift depending on concurrently active threats, session cookie theft remains a major security issue.

This highlights that ensuring timely session termination is highly critical, as an active session left open creates conditions for cookie interception to remain a potent attack vector. Furthermore, one must ensure user device protection—by using reliable antivirus software and frequently scanning systems for malware detection. Within the WordPress environment, it is advised to disable the „Remember me” function, thereby shortening cookie validity duration and curtailing potential attack opportunities ^[210].

The scale of the session cookie interception problem is also corroborated by an April 2025 study by NordVPN, revealing that in total nearly 94 billion browser cookies were stolen, out of which about 20% remained active. This data, gathered from users in 253 countries, was distributed via Telegram channels and the dark web. Cybersecurity expert A. Warmenhoven of NordVPN emphasizes that a stolen browser cookie equates in threat level to losing a password, because „once intercepted, accounts and sensitive information can be immediately accessed without any further authentication”, endangering hundreds of millions of users globally ^{[211, 212]}.

In light of these risks, it is practically important to apply solutions that secure session management control. One such solution is the „Inactive Logout” plugin (over 20,000 active installs, developer Deepen Bajracharya). This plugin allows administrators to establish an inactivity threshold after which a session is automatically severed. It is also possible to present users with an advance warning concerning impending logout, for example, via a countdown timer or a notification ^[213]. 

Complementing session duration management, proper cookie configuration is another fundamental security element. To mitigate their interception risk, specific security attributes are applied that limit session cookie transmission and accessibility. In the WordPress CMS, for instance, session cookie security can be fortified by editing the „wp-config.php” file and specifying these directives ^{[214, 215, 216, 217]}:

ini_set('session.cookie_secure', true);

ini_set('session.cookie_httponly', true);

ini_set('session.use_only_cookies', true);

Using an Activity Log Plugin

In the security architecture of information systems, the activity log is regarded as one of the fundamental components ensuring action transparency, accountability, and incident analysis capabilities. In the WordPress CMS, where user action control is based on flexible roles and broad administration functions, the activity log acquires particular significance as an integrated security tool ^{[220, 221, 222]}.

The purpose of an activity log is to systematically document user actions, including logins, password changes, privilege adjustments, content updates, plugin installations, or configuration tweaks. Such records assemble a coherent chronological event trail, permitting the identification of responsible parties and the precise determination of the time and nature of actions performed. This function is extremely vital during retrospective security incident investigations. Simultaneously, the logging mechanism acts as a preventative measure, as the awareness that actions are being recorded curbs abuse risks ^{[104, 220, 223, 224, 225, 226, 227, 228, 229]}.

Default WordPress features do not encompass comprehensive user activity logging, hence activity log functionality must be added separately. Depending on security needs and technical resources, this can be implemented leveraging specialized plugins or applying custom-built solutions integrated with external security or auditing systems. Among the most widely adopted plugins are the following:

• „Simple History – Track, Log, and Audit WordPress Changes” (over 300K active installations, developer Pär Thernström) ^[230];
• „Activity Log – Monitor & Record User Changes” (over 200K active installations, developer Elementor) ^[231];
• „WP Activity Log” (over 200K active installations, developer Melapress) ^[232];
• „Stream” (over 70K active installations, developer XWP) ^[233].

When selecting an activity log solution, it is vital to ensure data integrity and strict access control. The activity log loses its value if its entries can be edited, deleted, or forged by either system administrators or malicious actors. To guarantee reliability, it is critical that the log is stored in an independent environment, distinct from the primary WordPress database. A recommended practice is exporting the log to an isolated storage facility or integrating it with security information and event management (SIEM) systems ^{[221, 224, 234, 235]}.

Log viewing privileges are equally significant. While administrators generally receive top-tier access, abiding by security principles dictates that their access to viewing and managing log entries should be constrained. Such access must be assigned only to dedicated security and auditing entities who are independent of routine system administration. This segregation of duties preserves log integrity and objective event reconstruction even amidst internal threats, such as unauthorized administrative activity ^{[221, 224, 234, 235]}.

Ultimately, it is crucial to critically evaluate the scope and quality of the collected data. Responsible professionals must assure that the collected data is sufficient for an effective investigation of a potential security event, since inadequate information can hinder or totally thwart event analysis. In addition to the primary activity log, attention must be paid to other vital system logs, such as error logs, server activity logs, and authentication records. The analysis of these auxiliary logs offers a more complete context, permitting a more precise tracing of event progression and the identification of possible security breaches ^{[221, 234, 235]}.

Enabling HTTPS Protocol on a WordPress Website

With escalating data traffic, intensifying user interactions with online systems, and the broadening array of electronic services, secure data transmission becomes an indispensable portion of information system architecture. A key component of this security is the HTTPS (Hypertext Transfer Protocol Secure) protocol, which guarantees encrypted communication between the user’s browser and the server.

HTTPS is an extension of the HTTP protocol, bolstered by an SSL/TLS (Secure Sockets Layer / Transport Layer Security) encryption layer. When employing regular HTTP, data is transmitted unencrypted, hence susceptible to interception or modification. This risk is notably high for systems processing sensitive information—personal data, login credentials, or payment data. The threat is further amplified by public access points, such as free Wi-Fi networks, which cultivate favorable conditions for unencrypted information interception ^{[236, 237]}.

To assure security, deploying an SSL/TLS certificate is mandatory, providing site identity verification and facilitating an encrypted connection. Widely adopted free certificates, like „Let’s Encrypt”, are frequently already integrated into shared hosting services ^{[238, 239, 240]}. Nonetheless, the mere installation of a certificate is not enough—one must ensure that all website operations traverse exclusively via the HTTPS protocol.

Within the WordPress CMS, this process involves several steps. Firstly, base site URL settings are updated, converting them to HTTPS format. Next, mixed content is purged, which materializes when a page loads over HTTPS, but parts of its elements remain accessible via HTTP. Mixed content downgrades the protection level, can provoke browser warnings or even content blocking, making it essential to ensure all internal resources are loaded solely over a secure protocol ^{[241, 242]}.

Additionally, one can elevate administration zone security by defining a constant in the „wp-config.php” file ensuring that login and administrative actions are performed only over an encrypted connection ^[243]:

define( 'FORCE_SSL_ADMIN', true );

Once all site resources operate over HTTPS, mandatory redirection from HTTP to HTTPS must be implemented. This can be accomplished in a few ways ^{[242, 244, 245]}:

• Web server configuration (e.g., in the „.htaccess” file, using RewriteRule rules on Apache servers):

  RewriteEngine On
  RewriteCond %{HTTPS} off
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

• Through the „HTTP Strict Transport Security” header.
• Utilizing WordPress plugins that automatically ensure redirection and defense against insecure queries.

For smooth HTTPS deployment, plugins are often utilized, such as „Really Simple Security – Simple and Performant Security” (over 4M active installations, developer Really Simple Plugins) ^[113], which automates protocol conversion, redirects, and mixed content correction. However, for long-term reliability, it is recommended to prioritize proper server and CMS configuration, employing plugins solely as an assistive tool.

Upon completing configuration tasks, system operation verification is essential. External testing tools can be employed for this, such as Qualys SSL Labs’ „SSL Server Test” service (https://www.ssllabs.com/ssltest/), which offers a comprehensive analysis of the certificate, encryption configuration, and potential vulnerabilities ^[246].

Disabling XML-RPC Functionality in the WordPress Environment

XML-RPC (XML Remote Procedure Call) is a protocol created in 1998 by D. Winer (UserLand Software) and Microsoft, designed for remote procedure calls across a network. Data is transmitted within it via XML format, and communication occurs using the HTTP protocol. In the WordPress CMS, XML-RPC was integrated starting from version 1.5 (2005) to accommodate third-party app and service interaction with the platform. The protocol allows execution of assorted actions remotely—from authentication to creating new content, editing, or retrieving information, bypassing the browser’s administrative interface ^{[247, 248, 249, 250]}.

Initially, XML-RPC functionality was disabled by default, but users could activate it manually. Starting with WordPress version 3.5 (2012), this feature is turned on automatically, with its management settings purged from the user interface. This decision was made to simplify remote access for mobile devices and external publishing platforms ^{[249, 250, 251]}.

Over time, security researchers identified substantive vulnerabilities associated with XML-RPC. It has been documented that this interface can be exploited for automated password guessing (brute-force), denial of service attacks, as well as server IP address revelation even behind a web application firewall (WAF). Because of these risks, security recommendations emphasize evaluating in every case whether XML-RPC functionality is truly necessary for a given site. If not, it should be disabled or limited via supplementary defense measures ^{[248, 249, 250, 252]}.

Since WordPress version 4.7 (2016), the platform supports the REST API—a more modern mechanism for remote integrations. The REST API features broader functionality, greater performance, and more advanced authentication and access management capabilities. Therefore, in most instances, the REST API is regarded as a preferable solution over the antiquated XML-RPC ^{[248, 249, 253]}.

To reduce security risks, administrators can employ several XML-RPC disabling or restriction methods. They can be realized at both the web server and WordPress system levels ^{[248, 249, 254, 255]}:

• Web server configuration. Within an Apache environment, access to XML-RPC can be restricted in the server configuration or „.htaccess” file, for example:

  <Files "xmlrpc.php">
      Require all denied
  </Files>

• WordPress system configuration. The protocol’s functionality can be deactivated within the CMS itself utilizing a filter:

  function remove_xmlrpc_methods( $methods ) {
      return array();
  }
  add_filter( 'xmlrpc_methods', 'remove_xmlrpc_methods' );

In addition to altering server or WordPress configuration, XML-RPC functionality can be controlled using comprehensive security plugins, previously discussed in this article. These frequently offer the option to disable or restrict this interface as part of a wider toolset. Such a solution is uniquely helpful in instances where administrators lack direct access to the server environment yet desire to centrally manage multiple security features.

To verify the accessibility of XML-RPC functionality, the publicly available service „WordPress XML-RPC Validation Service” (https://xmlrpc.blog/) can be employed. This tool sends automated queries to the „xmlrpc.php” file and determines via the received response whether the XML-RPC interface is active and accessible externally ^[256]. 

Security Headers

HTTP security headers are HTTP response headers designated for security, through which a server communicates applicable security policy rules to the browser. They regulate content processing, resource loading, and browser actions, thus constructing a supplementary layer of protection. Correctly implemented security headers profoundly reduce the exposure risk to a variety of cyber threats ^{[257, 258, 259, 260, 261]}.

Despite their importance, the integration of security headers in websites remains disjointed and inadequate. A 2025 ServerAvatar study demonstrated that 84.66% of analyzed WordPress sites lacked properly configured security headers ^[180]. Akin results were unveiled by a 2024 analysis of over 3,000 sites, finding that 55.66% of evaluated sites failed to appropriately implement primary security headers ^[262]. Prior research corroborates this tendency: in 2020, Rapid7 identified that merely 7% of the top million Alexa list websites had installed an adequately configured content security policy ^[263]. These findings demonstrate that insufficient employment of security headers hampers browsers’ capabilities to efficiently guard users from content that may be weaponized for data theft, unauthorized redirections, or executing other pernicious actions.

Subsequently, several major security headers, applied in practice and comprising a crucial piece of browser protection mechanisms, are surveyed. It is vital to note that this overview is not exhaustive—more specialized headers exist. This chapter aims to familiarize the reader with the fundamental concept of security headers and their provided benefit; extensive information should be sought in official specifications.

1) Content Security Policy

The Content Security Policy (CSP) header delineates permitted resource origins that the browser is allowed to load and execute. By doing this, unauthorized or malicious code injection is constrained, diminishing the risk associated with XSS attacks wherein code injected into the site is executed in the user’s browser. Such attacks can result in user session hijacking, display of deceptive information, or other actions generating conditions for sensitive data leaks and ensuing cyber attacks ^{[264, 265, 266, 267]}.

The functioning of a content security policy centers around a collection of directives defining from which origins a browser can load specific resources. Each directive targets a particular content type, and their amalgamation enables forming a coherent security policy. The main fetch directives are:

• default-src – the default source when other directives are unspecified.
• script-src – origins for <script> elements.
• frame-src – origins for <frame> and <iframe> content.
• img-src – origins for images and other embedded (<embed>, <applet>) elements.
• style-src – origins for stylesheet files.
• font-src – origins for fonts.

Besides regulating resource loading, Content Security Policy acts as a formidable agent in guarding against clickjacking attacks. The premise of these attacks is to invisibly overlay an element (e.g., a button) of the targeted site onto a malicious site, deceptively coaxing the user to execute an undesired action. For protection against such attacks, the „frame-ancestors” directive is applied in the CSP, stipulating which external origins can embed the site into <frame>, <iframe>, <object>, or <embed> elements. This directive is perceived as more agile and functional than the obsolete „X-Frame-Options” header. Though both techniques can be utilized concurrently to ensure compatibility with older browsers, modern browsers confronting both headers prioritize the „frame-ancestors” directive ^{[268, 269]}.

It is imperative to underscore that Content Security Policy is not an overarching solution suited for all systems. The choice of directives must be individually tailored, factoring in specific system architecture, content nature, and distinct security needs. Below is an illustrative example of CSP header configuration:

Content-Security-Policy: default-src 'self'; img-src 'self' img.trusted-source.com;

In this illustration, the default-src ‘self’ directive dictates that by default, all resources can only be loaded from the same domain to which the webpage belongs. Meanwhile, the img-src ‘self’ img.trusted-source.com directive allows images to be loaded not just from the identical domain, but also from a specifically trusted source. Such configuration reinforces resource origin oversight and minimizes the risk of incorporating unapproved or potentially harmful resources onto the webpage.

2) HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a web security mechanism aimed at ensuring all requests between the user’s browser and the server transpire exclusively via the HTTPS protocol. This policy substantially mitigates the risk that, due to protocol downgrade or analogous attacks, the user is forced into employing an insecure HTTP connection. Such breaches could forge pathways for data interception or modification ^{[245, 261, 270, 271]}.

The HSTS policy is realized through the „Strict-Transport-Security” header, wherein directives are configured:

• max-age – sets the span (in seconds) the browser is compelled to use strictly HTTPS connections with a particular site. Before this term ends, attempts to connect over HTTP are blocked automatically.
• includeSubDomains – designates that the policy applies not solely to the parent domain, but also to all its subdomains, thus securing a uniform protection standard across the entire infrastructure.
• preload – implies that the site is enrolled in the browser-supported HSTS preload list. In this scenario, browsers, even prior to the initial request, recognize that HSTS must be applied to the site, hence HTTP connections are utterly blocked.

Nonetheless, the application of the preload directive warrants caution. Should the HTTPS configuration encounter an error or the certificate become invalid, browsers relying on the preload list will absolutely block access to the site. The service unavailability could endure until administrators re-establish correct configuration or browser vendors refresh the list. This procedure may take time, ergo haphazard HSTS header implementation can yield catastrophic outcomes for service availability ^{[272, 273, 274]}.

An illustrative example of the header:

Strict-Transport-Security: max-age=31536000; includeSubDomains

3) X-Content-Type-Options

„X-Content-Type-Options” is an HTTP response header intended to safeguard against MIME type sniffing attacks. If this header is absent, the browser may disregard the server-supplied „Content-Type” value and, relying on the file contents, try to decipher its type independently. This practice formulates a hazard that, for instance, a user-uploaded image embedding malicious code will be interpreted by the browser as executable content. This can spur XSS or alternative attacks premised on improper content processing ^{[261, 275, 276]}.

This header possesses a solitary value – „nosniff”, commanding the browser to strictly honor the server-declared „Content-Type” and execute no content analysis.

X-Content-Type-Options: nosniff

In summary, security headers comprise a substantial fraction of contemporary web defense, guiding browsers on proper interpretation of server-delivered content and lowering the peril of distinct attacks such as XSS. However, their prowess hinges on several elements: firstly, upon browser compatibility (older browsers might ignore some headers), secondly, upon precise configuration. Faultily configured headers could not only fail to bestow protection but also disrupt legitimate site functionality—for example, a too rigidly defined content security policy may block trusted resources, whereas an excessively liberal one might allow the loading of potentially detrimental content ^{[277, 278, 279]}. 

In the WordPress CMS, implementing security headers can be accomplished utilizing dedicated plugins. A universally adopted solution is the „HTTP Headers” plugin (over 50,000 active installs, developer Dimitar Ivanov) ^[280]. This tool supplies the capability to consistently apply most advised HTTP response headers, promising standardized enforcement of security policies and curbing configuration inaccuracy risks.

Disabling Error Message Display

During the development stage, displaying error messages on screen is a customary and indispensable practice aiding developers in locating and patching code flaws. In a production environment, however, this practice raises a considerable threat of information exposure. Publicly visible warnings shedding light on delicate technical details—such as server file paths, directory structure, component versions, or snippets of database queries—turn into reconnaissance instruments for threat actors ^{[281, 282, 283, 284]}. 

Intentionally instigating a system error is routinely among the primary attack steps, easing the discovery of weak points and the plotting of more precise, complex operations. Because of this, disabling visible error reporting in production systems is obligatory, confirming that all diagnostic data is securely documented in logs accessible exclusively to authorized subjects.

In the WordPress CMS, the main configuration file „wp-config.php” is utilized to configure safe error handling. It is advised to set these directives inside this file ^[285]:

// Disables the main WordPress debug mode.
define('WP_DEBUG', false);

// Disables WordPress error logging to the default "wp-content/debug.log" file.
define('WP_DEBUG_LOG', false);

// Disables error display on screen even if debug mode is on.
define('WP_DEBUG_DISPLAY', false);

// Disables debug mode, which tells WordPress to use
// non-minified versions of CSS and JavaScript files.
define('SCRIPT_DEBUG', false);

// Disables PHP error display on screen.
ini_set('display_errors', 0);

// Enables PHP error logging.
ini_set('log_errors', 1);

// Defines a secure path for the error log file.
ini_set('error_log', '/full/path/to/error.log');

One must consider that the „ini_set()” function could be disabled at the server level, particularly in shared hosting environments, where this is done for security motives. Owing to this, after modifying the „wp-config.php” file, it is mandatory to verify if the configurations took effect. If the „ini_set()” directives are disregarded, error handling must be configured through other measures. Dependent on the server environment, changes can be accomplished via „.user.ini” files, „.htaccess”, or a hosting control panel, provided such an option is granted.

Disabling Directory Indexing and Browsing

Directory indexing is a server feature allowing browser users to view the contents of a specific catalog if it lacks a default index file, for example, „index.html” or „index.php”. This feature is frequently tapped into during website building or testing to simplify file administration, but maintaining it enabled in a live setting can invoke serious security vulnerabilities ^{[286, 287]}.

Permitting the browsing of WordPress system directories can expose crucially vital information, encompassing plugin and theme file structures, versions, configuration files, or backups. Such an information leak equips cyber assailants with precious reconnaissance data, empowering them to map the website’s fragile points and orchestrate targeted attacks.

In shared hosting terrains, a majority of hosting vendors have disabled directory indexing by default to shield clients’ sites from information leakage. Yet confirming and securing these settings is still essential for every website administrator, since misconfigurations or the deployment of unstandardized resolutions can re-enable indexing. It is exceptionally perilous when search engines index such directories, consequently further boosting the danger of impending attacks.

A broadly prevalent reconnaissance tactic employed to pinpoint vulnerable systems rests on specialized search queries characterized as „Google Dorks” (or „Google Hacking”). This methodology exploits Google search operators to sieve search returns and spot particular configuration defects. As an example, the query intitle:”Index of” „wp-content/” can instantly unmask thousands of WordPress sites with active directory indexing ^{[288, 289, 290, 291]}. 

The perils and practical illustrations of utilizing these queries are analyzed in a 2021 article by D. Sveikauskas, published on the PatchStack cybersecurity platform’s blog. The piece investigates how utilizing predefined queries identified publicly accessible catalogs harboring sensitive files, such as „wp-config.php.txt” or website backups. According to the author, such data exposures afford even an inexperienced hacker access to confidential information without specialized tools and enable site hijack in short order ^[292].

To curtail the danger of illicit access to sensitive data, it is advised to disable directory browsing functionality within the server configuration. As an example, on Apache servers this can be attained in the „.htaccess” file by declaring the „Options -Indexes” directive, and on Nginx servers by implementing „autoindex off;” within the configuration block. These configurations guarantee that, lacking a default index file, the server won’t return the directory’s content roster, but will instead dish out an error notice, thus diminishing the prospect of potential information leakage ^[293].

Disabling the Built-In File Editor

Deactivating the file editing utility in the WordPress CMS is an important security habit devised to protect the site from illegal or accidental code alterations via the administrative dashboard. By default, WordPress allows administrators to directly alter theme and plugin files using a built-in editor via the browser. While this utility can be practical during testing or production, it is deemed a security hazard on active websites ^{[294, 295]}. 

Flaws of this nature pave the way for the integration of malware into the website landscape. One commonly met tool is a so-called backdoor, assigning illegal and sustained system entry even subsequent to administrator password modifications or the enactment of ordinary defense procedures. Another behavior is program code injection aimed at collecting confidential facts, for instance, authentication details, browser cookies, session identifiers, or payment specifics. 

One instance illuminating the inherent editor risk is a large-scale cyber drive noticed in 2020, zeroing in on close to a million sites relying on the WordPress CMS. Throughout the attack, recognized vulnerabilities within prevalent plugins and themes were exploited, authorizing the injection of malevolent JavaScript code into the site’s environment. The essential aim of this code was deducing if the browser’s user was signed in as an administrator. Upon uncovering an active administrative session, the integrated code initiated file modifications via the administrative interface and established a remote, sustained-access malicious component inside the theme files ^[296].

To moderate the alluded risk, it is advised to declare the below-mentioned constant in the „wp-config.php” configuration file, disabling the file altering capacity through the WordPress administrative dashboard:

define('DISALLOW_FILE_EDIT', true);

This countermeasure removes theme and plugin editors from the administrative interface, thus shrinking the odds of uploading destructive code or undertaking illegal revisions devoid of direct server admission. Striving for a loftier security plateau, an additional constant may be implemented:

define('DISALLOW_FILE_MODS', true);

The latter not merely barricades file editing, but also universally disables the ability inside the administrative interface to mount, remove, activate, or update plugins, themes, and even the WordPress core edition itself ^[297].

Restricting Access to PHP and Other Sensitive Files

A core security canon applicable to CMSs powered by WordPress is quarantining executable files, principally PHP, from open public reach. This tactic significantly mitigates the danger intertwined with malicious code uploading and execution, mostly manifesting owing to security defects in file upload functions ^[298]. Relying on the CVE (Common Vulnerabilities and Exposures) database, a query for the keywords „wordpress file upload” divulges around 1,000 documented vulnerabilities attached to file upload mechanisms—affirming the gravity of this sector in a security contour ^[299].

The directory „/wp-content/uploads/” in the WordPress habitat is appointed for storing user-uploaded files. More often than not, this is graphical or documentary material, such as pictures, PDF files, or similar items. Keeping this purpose in mind, this directory should not lodge files harboring software code capable of being executed on the server (e.g., PHP files). Nevertheless, in reality, this hub is frequently harnessed for ill intents, specially when intruders manage to circumvent file upload safety mechanisms. Under these circumstances, a hazardous file packing executable code can be dropped into the directory, which is later triggered utilizing a direct HTTP query, for example, by hitting the relevant URL in a browser ^{[300, 301, 302]}.

To evade this peril, it is suggested to ban any execution of active content within this directory at the server level. Beneath is an illustrative „.htaccess” configuration sample aimed at Apache web servers, granting access uniquely to permitted files:

# Deny access to all files
<Files "*">
    Require all denied
</Files>

# Allow access to images
<FilesMatch "(?i)\.(jpe?g|png|gif|webp|avif|heic|heif|bmp|ico|tiff?)$">
    Require all granted
</FilesMatch>

# Allow access to video files
<FilesMatch "(?i)\.(mp4|webm|ogg|avi|mov|wmv|flv|m4v|mkv|3gp|ogv)$">
    Require all granted
</FilesMatch>

# Allow access to documents
<FilesMatch "(?i)\.(pdf|doc|docx|xls|xlsx|ppt|pptx|odt|ods|odp)$">
    Require all granted
</FilesMatch>

# Allow access to styling and Javascript files, if necessary
<FilesMatch "(?i)\.(css|js)$">
    Require all granted
</FilesMatch>

This layout ensures that only assigned file categories will be accessible via direct HTTP requests, while all subsequent files, incorporating potentially detrimental executables, will be mechanically blocked. Such a path is safer than solely blocking harmful extensions, considering the latter hinge upon a roster of noted threats that might be deficient. Preceding the application of this habit, it is crucial to assess whether indispensable system assets, like JavaScript or CSS files frequently employed in plugins, aren’t among the restricted files. 

Analogous security protocol should be employed to other directories, say „wp-content/themes” and „wp-content/plugins”, keeping theme and plugin files. Though PHP files are typically discovered in these directories, in most occasions their overt execution via HTTP queries is unneeded ^[355]. In theme directories, it is generally enough to confirm the availability only of static assets, such as pictures, CSS, or JavaScript files.

Plugin directories warrant deeper evaluation. Files deployed by a specified plugin can manage myriad functions, like file uploads, answering REST API requests, or orchestrating automated jobs. Hence, prior to administering access boundaries, it is necessary to undertake a complete review and decide which files are obligatory for right system operation. Merely after discharging such an analysis can grounded decisions be forged, providing an equilibrium between safety and utility while dodging unforeseen website breakdowns.

The directories „/wp-includes/” and „/wp-admin/includes/”, as stated in the documentation addressed to WordPress engineers, ought not be directly available via HTTP calls. Integral systemic files aimed for inner processing are stowed in these directories, ergo their external exposure can represent a hazard to safety. The documentation yields an endorsed „.htaccess” configuration specimen ^[174]:

# Block the include-only files.
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /
    RewriteRule ^wp-admin/includes/ -[F,L]
    RewriteRule !^wp-includes/ - [S=3]
    RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
    RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
    RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

# BEGIN WordPress

Besides directory access restrictions, no less scrutiny needs to be assigned to protecting individual delicate files, uniquely those stockpiling confidential facts or whose content might be leveraged to discern system susceptibilities. A pivotal such file is „wp-config.php”, wherein database connection details, authentication keys, and other vital system choices are stipulated.

This jeopardy is clarified by a wide-range offensive campaign noticed in late May 2020, scrutinized by Wordfence. In the course of a few days, their firewall mechanism thwarted over 130 million shots to grab the „wp-config.php” file from 1.3 million sites. These attacks struck familiar safety holes in plugins and theme files, conceding access to inner WordPress assets ^[303]. 

Should the server setting authorize it, it is recommended to transplant the „wp-config.php” file past the publicly accessible web root bounds. Such a measure forms a complementary degree of defense independent of the server’s internal access restriction ordinances. This custom is intensely relevant in situations where due to server steering blunders, patches, or erroneous configuration, the PHP processor might halt executing PHP files and in lieu present their output as pure text. Seeing that the „wp-config.php” file saves classified data, such an occurrence could bring about a drastic information safety breach ^{[174, 304, 305]}. 

If transplanting the „wp-config.php” file beyond the web root constraints is not viable, it is compulsory at the server setup level to bar entry to this alongside other fragile files. Such items incorporate not simply primary setup or setting records, but additionally database exports, backup duplicates, archives, version tracing metadata, and texts that could potentially unveil lucrative data to a hostile party. Below is presented an illustrative „.htaccess” structure model fashioned for Apache web servers, blocking entry to numerous files:

# Critical configuration files
<FilesMatch "^(wp-config|config|configuration)\.php$">
    Require all denied
</FilesMatch>

# Databases, backups, and configuration templates
<FilesMatch "\.(sql|db|sqlite|sqlite3|bak|backup|old|orig|save|tmp|temp|log|logs|inc|conf|dist|sh|class)$">
    Require all denied
</FilesMatch>

# System configuration and version control files
<FilesMatch "^\.(htaccess|htpasswd|env|user\.ini|access|passwd|git|svn|hg|bzr)">
    Require all denied
</FilesMatch>

# Archives, templates, and source files
<FilesMatch "\.(zip|tar|gz|bz2|7z|rar|fla|psd|tpl|twig)$">
    Require all denied
</FilesMatch>

# Documentation, licenses, and update history
<FilesMatch "^(readme|changelog|install|upgrade|license).*\.(html|txt|md)$">
    Require all denied
</FilesMatch>

File Permissions

File permissions are an operating system-level security device engineered to control admission to files and directories. They pinpoint what authorizations discrete users boast towards specific file network elements. Accurately tuning these grants is pivotally key to promising system security ^{[306, 307, 308, 309]}.

In Linux frameworks, natively most broadly leveraged in web server ecosystems, the authorization model hinges on three user groups: owner, group, and others. For every group, three major privileges can be dispensed: read (value – 4), write (value – 2), and execute (value – 1) ^{[307, 308, 309]}.

Permissions are conveyed in a three-digit octal form – every numeral points to the collective privileges for the respective user category. For example, a permission mode 755 suggests that the owner owns complete rights (4 + 2 + 1 = 7), while the group and alternative users enjoy solely reading and carrying out rights (4 + 1 = 5).

Within the WordPress frame, file permission superintendence is an imperative safety leadership facet. Falsely configured allowances may create environments for malicious script placement or delicate file viewing. While appointing grants, one must follow the principle of least privilege, assigning to every system actor only those rights needed to actualize their tasks ^{[308, 310, 311, 312]}.

Regardless, observing this principle demands finding a symmetry between protection and system operability. Excessively stern grant settings could hinder WordPress processes, whilst overly lax ones yield security crevices.

Building upon WordPress documentation and defense routines, the accompanying allowance setups are advised ^{[308, 310, 311, 312]}:

• for directories – 755
• for files – 644
• for the file „wp-config.php” – 640 or 644

Aiming to promise a taller security benchmark, it is backed to adopt fiercer entry allowance modes to key items. As a case, for the file „wp-config.php”, safeguarding prime setting inputs, determining permits to 440 or 400 is proposed. Using this route, read freedoms are granted merely to the owner or a fixed group, while penning privileges are totally checked. This method curtails autonomous applications or illegitimate parties, including the WordPress platform itself, from adjusting the file’s material, thus softening the threat joined to compromises or unwanted shifts. Subject to necessity to refresh or morph the setup, grants can be shifted to 644, and reestablished to the protected structure after changes. Parallel entry commands should be employed for added crucial items or domains.

It is supremely central to evade 777 grants, lending unqualified access to all bodies and parties – this layout may compose occasions for harmful code deployment and activation.

File Integrity Monitoring

Unauthorized systemic item changes continue being one of the central hurdles of current cybersecurity. Consulting the 2023 Sucuri report, a remarkable 49.21% of subverted portals carried at least one stealth system access path (backdoor) ^[12]. Struggling to elude automated security instrument detection, digital offenders progressively apply intricate techniques that allow discreetly planting malicious scripts into CMS elements.

An instance mapped out on the Wordfence blog bares a delicate malicious script camouflage method, the essence of which is multi-layered disguise. Destructive code was placed into an outwardly ordinary software file, where perilous operations fit for deploying supplementary ruinous content were encoded via numeric and alphabetic equivalents matching an alphabetic order. This way not solely complexly masks the primary script, but its hurtful substance was masked beneath another coat – an image piece, finding of which via habitual security means turns immensely challenging. Thusly an array of masking platforms cemented a fruitful integration of unauthorized entry ^[313].

An illustration narrated by Foregenix highlights how fine security extension alterations can generate critical and enduring consequences. By burying solely two additional script strings, two basic ends were captured: one string dismantled the security platform’s file check trait, smoothly suppressing hazard detection, while the other halted item upgrades, stopping its reinstatement to a pure form ^[126]. This demonstration underscores how modest, yet strategically planted modifications might award offenders continuous, unseen access to compromised framework.

File transformations of this nature clarify why file integrity monitoring (FIM) is reckoned a requisite routine of modern cybersecurity. This mechanized stream lets spotting any unauthorized or unpredicted system file changes, sporadically benchmarking file contents with a pre-recorded trusted foundation. Noticing mismatches instantly initiates intervention routines, delivering the prospect to accurately pinpoint feasible breaches and soften their injury before magnification ^{[314, 315]}.

For file integrity tracking, cryptographic hashing mechanics (e.g., SHA-256) are used, stamping each document a distinctive numerical mark. Consistently scrutinizing the steadiness of these signatures confirms dependable awareness of unapproved amendments even in the slightest item bit ^{[314, 315]}.

An even superior defense altitude is struck bringing in products that not just map file variations but intrinsically reboot broken assets back to base shape, taking for instance an uncorrupted backup. Such wares ensure an effective and swift reply to security events and sizably lessen probable harm risks birthed by malware.

Encompassing security extensions tackled in previous article spans, such as Wordfence, Sucuri Security, MalCare and others, confer the capacity to observe file integrity within the WordPress mechanism. Outside local scrutiny, these units frequently compare system components with official builds housed inside the WordPress.org cache, thus offering greater system unity trust ^{[98, 99, 109]}.

It is central to emphasize that united WordPress defense tools can serve as a primary hit goal, when malefactors strive to pull them down or rewrite them. Therefore a portion of defense machinery ought to operate unbound from the CMS. This is affected mapping separate software items or server-level devices. E.g., widely adopted OSSEC, AIDE, or Tripwire mechanisms eye filesystem alterations unattached from WordPress or adjoining CMS components ^{[316, 317, 318, 319]}. Instruments like these favor spotting not merely WordPress item revisions but variations of secondary system elements, thereby setting up an added safety mantle.

Changing the Default WordPress Database Prefix

The WordPress CMS by default configuration assigns a table prefix „wp_” to database tables. Even though this parameter doesn’t have an outright sway over platform functionality, it can emerge as an objective for automated large-scale SQL injection campaigns. If the default prefix setting stays, deploying attack storylines proves simpler, seeing that a chunk of automated raids lean on the presumed table map. Whenever supplementary flaws exist on the portal, explicit finding of table designations awards assailants an edge. Therefore inside the launching installation phase it’s advised to swap the table prefix to a unique sequence of characters, for instance, „x7rt5_” ^{[320, 321, 322]}.

Contrasting the referred pros, reconfiguring the table prefix is regularly condemned inside the security sphere, given that it hinges on the „security through obscurity” standard. It is contested that if an invader already boasts the ability to cast hostile SQL prompts, from a tech view it is not troublesome for them to dispatch accessory queries leading to the listing of all catalog table monikers and their prefixes. This gifts the aggressor an avenue to glean detail surrounding the data matrix layout and plot subsequent exploitation steps ^{[107, 322]}.

Whilst altering the table prefix by its lonesome doesn’t amount to a robust defense shield, it can snarl executing invasions in certain occurrences. Nonstandard table moniker setup impairs the enacting of mechanized campaigns grounded on regular names. Such impact might be salient facing unadjusted automated missions where the aggressor fails to perform data mapping or targeted ambushes. 

As signaled inside the WordPress engineers’ files, tweaking the table prefix starting from the default „wp_” can thwart at least a share of conceivable strikes ^[174]. Even so, this trick operates merely as an accessory prophylactic stride, which doesn’t suffice for shielding against more progressive or deliberately thrown attacks. Hence, it ought to be integrated inside a multi-tiered security blueprint joined with extra confirmed security customs, like software update administration or deploying a firewall.

Tweaking the table prefix inside an already running WordPress setup, the primary and chief procedure is to form a full data matrix backup. This is compulsory striving to ensure record retrievement amidst any blunder or unreckoned consequence, subsequently keeping away out of achievable info loss.

Moving forward it is imperative to rework the config record „wp-config.php”, wherein the constant „$table_prefix” is discovered. The sum of this constant is twisted out of the standard „wp_” over to the decided fresh prefix, e.g., „x7rt5_”:

$table_prefix = 'x7rt5_';

Pursuing an assurance of network run minus halts, it’s compulsory to retitle complete base tables, mutating their prefix fitly to the novel. This operation is most broadly pulled off running SQL calls similarly like:

RENAME TABLE wp_options TO x7rt5_options;

RENAME TABLE wp_posts TO x7rt5_posts;

RENAME TABLE wp_users TO x7rt5_users;

These exercises must be redone for every matrix table, engulfing tables built by supplemental plugins or themes.

Additionally, inside specific catalogs, preeminently „x7rt5_options” and „x7rt5_usermeta”, inputs are parked that even now sport the antiquated prefix. Therefore it is required to upgrade these counts as well by casting SQL inquiries, for instance:

UPDATE x7rt5_usermeta SET meta_key = 'x7rt5_capabilities' WHERE meta_key = 'wp_capabilities';

UPDATE x7rt5_usermeta SET meta_key = 'x7rt5_user_level' WHERE meta_key = 'wp_user_level';

UPDATE x7rt5_usermeta SET meta_key = 'x7rt5_autosave_draft_ids' WHERE meta_key = 'wp_autosave_draft_ids';

UPDATE x7rt5_options SET option_name = 'x7rt5_user_roles' WHERE option_name = 'wp_user_roles';

Proceeding these measures it is suggested to refreshingly activate total add-ons and themes tapped upon the site, for the platform to refresh internal bridges and assure all gears play nicely alongside the new prefix.

Protection from Automated Bots

Over the last years the web environment has swiftly transformed: a mounting share of traffic is comprised of automated bots. Calling upon the „Imperva Bad Bot Report 2025”, for the first stretch inside a decade automated load outpaced human-crafted movement – in 2024 it made up 51% of whole global web flow. This leap was hugely powered by the quick fielding of AI and Large Language Models (LLMs), rendering it prominently gentler to architect refined, adaptive bots ^[324].

Automated software is predominantly separated into „good bots” and „bad bots”. Excellent bots pull off meaningful traits, identical to search engine crawling (like Googlebot), domain observation, or uptime trailing. However the chief distress is sparked by vicious bots’ behavior, which conventionally gets automatic, unlawful, and centered upon damaging matter spread, info scooping absent sanction, service disrupting coupled with efforts to misuse structural security chasms. In 2024 the bad bots segment held 37% of whole cyber flow, whilst in 2023 this bulk measured 32%. Such an escalation clearly paints the booming breadth of computerized dangers on the net ^{[324, 325]}.

An investigation tackled by cybersecurity firm HUMAN’s threat intellect branch „Satori Threat Intelligence”, exploiting a notably fitted webpage engineered for computerized bot activity surveillance (a honeypot), illustrated that vulnerability scanners figure amid the foremost to encounter a newly molded website. Once the portal steps live, these bots methodically dig for administrative interfaces, layout bloopers, and insecurely left bits. Driven by survey stats, within initial days scanner-summoned flow measured a mean around 70% of entire bot deeds, and on individual frames jumped even to 100% ^[326]. These results underscore that even nascently released sites instantly land inside the global robotic scanning grid.

Content oversight frames, like WordPress, rate among the most frequent robotic bot attack marks, predominately owing to uniform skeletons, universally spread plugins and themes, as well as publicly charted default settings. Because of these reasons it’s incredibly decisive to field composite tech means, conceding on-time naming of unsolicited bot motion, restricting their entry, or wholly barring it. Below are analyzed resources and their practical delivery defending websites off mechanized threats.

1) Geographic Filtering

Geographic restricting (geoblocking) – is an admission authority scheme where the user flow is curbed or repelled looking into their whereabouts, resolved by IP address. This tool acts exceedingly forcefully in occurrences when services are targeted upon certain regions, and is popularly invoked striving to deflate automated or malicious traffic peril ^{[167, 168, 169]}.

Access log reviews are exerted aiming to tag regions out of which climbs a higher hostile conduct bulk. Mainly this wraps pushes to rip the site skeleton, sign-in form salvos, or notorious flaws’ exploitation. Amid such instances pointedly utilized geo-restriction, operating along allied protection means, say, logical puzzle solving or outright command blocking, aids to capably curtail attack hazard and perfect server resource handling, since ruinous flow is tossed out even in a preliminary phase ^{[327, 328, 329]}.

For geoblocking rollout cloud-steered safety nodes are usually called upon, mirroring Cloudflare. A trait of this suite – Web Application Firewall (WAF), performing as an intermediary shield level between the patron and site server. If Cloudflare handles inside a reverse proxy stance, all arriving stream at first navigates across its globe-spanning data centers web ^{[82, 90, 172]}.

This flow is analyzed prior to it greeting the primary site server. An analytic touchstone – user’s location point. Gleaned intelligence gets checked against pre-drafted access dictums, granting access constraints under geographical gauges. Supposing a request skips satisfying the shaped constraints, the setup may automatically impose assorted guard devices. A generally resorted approach – secondary verification, e.g., a CAPTCHA challenge, enabling distinguishing automated feed from factual guests. Meanwhile, hits off elevated jeopardy zones, whereat utilities are disabled or much baleful running is traced, might encounter harsher clamps, analog to IP address lockouts ^{[172, 330, 331]}.

While cloud formulas enable porting screening onto an exterior web, WordPress portals could harness plugin-powered blocking engines. The operation of such add-ons centers around IP geolocation databanks, clearing a path to place the caller’s spot and launch fitting admission bounds per upfront drafted norms. Exemplars of such plugins:

• IP2Location Country Blocker (over 30K active installations, developer IP2Location) ^[332];
• iQ Block Country (over 20K active installations, developer Pascal) ^[333];
• IP Location Block (over 10K active installations, developer Darko G.) ^[334].

It’s important to grasp that these plugins can pose harmony snags accompanying caching plugins, thence it is imperative to exhaustively assay and trial the holistic site usability. Correspondingly one must observe that these pieces skip sporting accessory validation machineries, identical to CAPTCHA tests, that foster segregating actual clients off mechanistic networks. Nevertheless, such add-ons may turn effective during situations when elevated peril regions are tracked, wherein solutions are absent, or if the website spots fierce computerized activity, asking for a swift guard reaction.

It is likewise commended to appreciate that several WordPress plugin-seated intercept tools influence alone those calls that get processed within the CMS native bounds. Forthright inquiries toward single documents, say, shots or pages, repetitively skirt these blockades. In light of this rational it’s encouraged to estimate if existing defense architectures clasp these hits too, and amid an amplified jeopardy degree – muse about attached server or network plane sorting strategies.

The geographic separating role is similarly blended inside multiple complex safety plugins, which were more extensively reviewed inside preceding chapters of this paper. In such plugins geographic throttling regularly runs like a collateral buffer layer together spanning extra modules, take for example, login oversight, IP label lockdown, or automatic blow sensing gears. The fusion of these attributes warrants breeding an overarching shell, which not just bounds entry honoring earthly roots, but upgrades the common structural resilience handling multifarious cyber dangers.

Finally, geographic locking arrangements can be put into play via various physical tiers – kicking off from applicative (e.g., CMS plugins) ending at server or link picking protocols. Deciding upon the matching implement ought to be fueled by structural anatomy, tagged stakes, and performance urgencies. Desiring summit potency, it matters that unwanted traffic suffers refusal at the earliest stage possible – inside the so-titled perimeter tier, i.e. even preceding it grabbing interior server assets. Tools like cloud-stationed firewalls facilitate not alone lowering server strain, but besides neutralizing prospective clashes at an early lap. As a result geographic restriction elements should be reasoned strategically, acknowledging inside which infrastructure leaf their application will yield the utmost security and operational productivity gain.

2) CAPTCHA Deployment in Interactive Forms

CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) – is a protective feature designated to deduce if designated endeavors within a structure get carried out via a human or mechanistic software. Subject to the applied verification means, answers can be script-based (demanding typing deformed script), visual (reliant on item recognition among images), or conduct-rooted (studying mouse flow, entry pace, and browsing habits). These barricades are knitted inside interactive site fragments where a huge mechanized mistreatment danger arises – instance given, in login and signup views, contact portals, or digital commerce checkout routines ^{[336, 337]}. 

Downwards are cited distinct globally employed items shaping this branch:

• „Advanced Google reCAPTCHA” (over 200K active installations, developer WebFactory) ^[163];
• „hCaptcha for WP” (over 70K active installations, developer hcaptcha) ^[164].

3) Honeypot Methodology

Honeypot (literally – a honey pot, in the IT sector meaning intentional traps for catching malicious activity) – is an information system protection measure based on deliberately created deceptive resources. The purpose of these resources is to divert automated or malicious activities away from real systems or their components, as well as to collect information about potential violators and the nature of their activities. Depending on the application context, a honeypot can be realized at different levels – from hidden input fields in web forms to dedicated servers or services imitating real targets ^{[338, 339, 340]}.

These baits often act as interaction traps – atypical login attempts, field fillings, or other actions are recorded, allowing the identification and analysis of malicious activity. Such monitoring allows not only to detect known threat models but also to reveal newly emerging vulnerability forms and attack vectors. Therefore, the honeypot method becomes a valuable tool in developing preventive defense strategies and improving the overall security architecture ^{[338, 339, 340]}.

In content management systems like WordPress, the honeypot method is most commonly applied by integrating visually invisible input fields into the structure of web forms. These fields are neither visible nor accessible to the user through regular browser interfaces, therefore they are not filled out manually. Meanwhile, automated systems that process all form elements often fill out these fields. This behavioral model allows identifying malicious requests, thus creating conditions for their early rejection. The following specialized plugins can be used to implement these solutions:

• „WP Armour – Honeypot Anti Spam” (over 300K active installations, developer Dnesscarkey) ^[341];
• „AntiSpam for Contact Form 7” (over 10K active installations, developer Erik) ^[342].

Another widely used form of detection bait is deliberately inserted links hidden in the user interface within the structure of a website page. Such links are not accessible to the user via the graphical browser interface, but they can be detected and activated by automated programs. Interaction with these links can be used to identify automated data collection systems and to initiate restrictions on their activity, for example, by applying IP address blocking. The integration of such hidden links can be achieved with the following plugin:

• „Blackhole for Bad Bots” (over 30K active installations, developer Jeff Starr) ^[343].

The methods described above are most often deployed in the WordPress environment for practical reasons – to reduce server load and filter harmful automated traffic. However, the effectiveness of such measures is limited because more advanced automated systems can analyze the page structure, identify atypical elements, and bypass these mechanisms. Therefore, detection baits are most effective in the context of mass, less sophisticated threats, but a broader, multi-layered security strategy is necessary for protection against targeted, more sophisticated attacks.

It is important to note that the honeypot methodology is not limited only to plugins or the browser interface level. In the broader context of information systems, fake administration pages, counterfeit files imitating sensitive data, or artificial API endpoints can be created. In some cases, such baits are used not only for prevention but also as an active measure to deceive the attacking entity – diverting its actions from real resources or systems. The success of such a strategy depends on the ability to flexibly adapt to the changing nature of threats and the creative use of available technical means.

4) Browser and HTTP Headers Analysis

One of the widely applied methods for restricting automated system access to web services is client identification based on data transmitted during requests. This data is automatically recorded by the server when a user initiates a connection to the website. Commonly evaluated parameters include user-agent information, IP address, cookies, and other HTTP header attributes, such as accepted content formats or language settings. By analyzing these parameters, it is possible to preliminarily identify whether the request was initiated by a human using a browser or generated by an automated system ^{[344, 345]}.

Among these parameters, user-agent information is considered particularly significant – it is an HTTP header field containing data about the client software: browser type, version, operating system, and other technical aspects. This information is often used as one of the primary criteria in classifying requests, aiming to distinguish a regular browser user from a search engine bot or a potential automated tool. Some systems openly declare their identity, so a keyword search method is often applied, identifying strings containing terms like „bot”, „crawler”, or „spider”. Below are representative examples of user-agents ^{[346, 347, 348, 349, 350, 351]}:

• „Google Chrome” browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36 ^[347];
• „Google” search engine bot: Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36 ^[348];
• „Ahrefs” SEO analysis bot: Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/) ^[349].

However, the reliability of such a method is limited. On one hand, it can mistakenly restrict legitimate bots, so exceptions must be provided for the activities of search engines like Google or Bing. On the other hand, the user-agent value is declarative and can be forged ^[352]. This loophole is often exploited by malicious systems that submit forged values imitating legitimate browsers or even search engine bots ^{[353, 354]}. Therefore, for reliable identification, it is recommended to apply additional verification mechanisms based on the official technical requirements of service providers, such as the two-step DNS verification procedure offered by Google, or to rely on official IP address lists ^[355].

Additionally, the analysis of HTTP header structure and stability is significant. Empirical studies show that one of the signs of suspicious activity is a constant change in the user-agent value – situations where requests with different agent values are received from a single IP address within a short period. A normal browser session features a stable user-agent value, making such deviations considered atypical. Furthermore, automated activity can also be given away by other non-standard header form aspects, such as the absence of typically provided headers, discrepancies in their layout, inconsistent use of upper and lower case letters, or submitting multiple versions of the same header. The totality of these anomalies constitutes a reliable indicator allowing the identification of automated requests and distinguishing them from legitimate browser traffic ^{[356, 357, 358, 359, 360]}.

In addition to HTTP headers analysis, it is important to consider other technical features that allow for more precise determination of automated systems. One such feature is the client’s ability to execute JavaScript code. According to research data, only a small fraction of automated systems support this functionality: out of over 1.7 million analyzed sessions, only 0.63% were able to actively perform actions in the browser, for example, updating content or obtaining additional information without reloading the page ^[356].

In a practical environment, these methods are often supplemented by filtering tools operating on the basis of static rules. Among them is the „8G Firewall” – a server-level filtering mechanism that performs basic firewall functions. This tool relies on pre-defined rule sets and blocks requests corresponding to signs of malicious activity, such as unauthorized URL parameters or malicious bots identified by the user-agent, thereby providing the function of a primary defense layer ^[361].

5) Reputation-Based Blocking

Reputation-based blocking is one of the proactive cyber defense measures allowing for the advanced identification and rejection of requests from sources with a negative activity history. This method is based on external databases and monitoring systems that accumulate information about IP addresses or other identifiers related to malicious activity. Such a preventive strategy enables mitigating risks even before a potential attack is initiated and utilizing system resources more efficiently ^{[362, 363]}.

One of the most widely applied reputation analysis tools is IP blacklists. These are specialized databases storing IP addresses related to unwanted or malicious activity, such as spam sending, automated content scanning, or denial of service attacks. These lists are constantly updated using both automated monitoring mechanisms and community reports. By implementing blacklists in firewall configuration, network filtering systems, or other server-level protection measures, suspicious requests can be blocked automatically. Several publicly available and widely applied lists can be singled out as examples, such as AbuseIPDB, Project Honeypot, and FireHOL, which are actively maintained and frequently integrated into various cybersecurity platforms ^{[364, 365, 366]}.

However, IP address blocklists have significant limitations. Studies show that their coverage is fragmented: for example, out of more than 76,000 IP addresses demonstrating malicious behavior, only 13% were recorded in popular lists ^[356]. Other authors have presented similar conclusions, emphasizing that the results of public databases vary greatly – in some cases, the coverage reaches around a dozen percent, in others it can be significantly higher, but in no case is a comprehensive identification of malicious addresses ensured ^{[367, 368]}. These limitations mean that blocklists should not be perceived as an independent defense measure, but rather as an additional component in a broader security architecture.

In conclusion, despite limited coverage, IP address blocklists remain an important part of cyber defense. They help mitigate the impact of mass malicious requests, optimize the use of system resources, and prevent a portion of automated attacks. Therefore, the integration of these lists into a multi-layered protection strategy is an important factor in ensuring the resilience of information systems against cyber threats.

6) Traffic Analysis

One effective automated request identification method is systematic HTTP 404 error analysis, allowing the recognition of requests directed at non-existent resources. Such requests most often originate from automated tools that, attempting to detect security flaws, methodically check a large number of different addresses, such as login forms, administration interfaces, configuration files, or other potentially vulnerable files. Since the scope of checked addresses is usually very wide, a large portion of them do not exist in the target system, causing the server to return 404 error responses. Although isolated instances are a normal part of legitimate browsing, a large number of them in a short period from a single source is considered a significant indicator of malicious activity. Once such traffic is identified, responsive measures can be applied, for example, temporary IP address blocking ^{[369, 370, 371]}.

Another significant protection method is rate limiting. This technique defines the maximum allowable number of requests that a single source can submit within a set period. Once this limit is exceeded, further requests may be temporarily blocked or slowed down. It is important to note that when applying this method, appropriate limits must be set: overly strict restrictions can disrupt the activity of legitimate users, while overly loose ones may not protect against automated attacks ^{[372, 373, 374]}.

It must be noted that both discussed methods are based on client IP address activity monitoring, so their effectiveness decreases in cases where attacks are carried out in a distributed manner from many different sources or when slow-paced scanning methods are used. In such situations, the number of requests from a single address may not exceed the set limits, leaving the malicious activity unnoticed. Despite this limitation, the mentioned methods can play an important role as an additional protection layer, helping to mitigate the risk from less sophisticated automated attacks.

Finally, to ensure effective protection against automated requests, it is necessary to apply a comprehensive set of protection measures forming a multi-layered defense system. It is important to note that the cyber threat infrastructure is extremely dynamic, so protection methods must be adaptive and include continuous log audits, anomaly identification, as well as the updating of filtering rules and IP reputation lists. Only a consistent cycle of monitoring, analysis, and response can ensure long-term and reliable resilience against ever-changing threats.

Backups

Data backups are an essential information system security and business continuity measure, ensuring data availability, integrity, and recovery capabilities after technical failures, cyber attacks, or other unforeseen incidents. The application of this mechanism is especially important in the context of content management systems, as it allows restoring stable website operation following disruptions related to malicious code impact, content loss, software component incompatibilities, or errors during updates. Backups typically encompass the database, where content and user information is stored, and the software infrastructure, including plugins and themes, thus ensuring full system restoration and business continuity ^{[375, 376, 377, 378, 379]}.

The default features of the WordPress content management system do not provide an integrated and comprehensive backup mechanism, so ensuring backups mostly relies on capabilities offered by website hosting providers or specialized plugins. Below is a list of plugins providing backup creation functionality, reflecting widely applied solutions:

• „All-in-One WP Migration and Backup” (over 5M active installations, developer ServMask) ^[380];
• „UpdraftPlus: WP Backup & Migration Plugin” (over 3M active installations, developer Team Updraft) ^[381];
• „Duplicator – Backups & Migration Plugin – Cloud Backups, Scheduled Backups, & More” (over 1M active installations, developer Syed Balkhi) ^[382];
• „Migration, Backup, Staging – WPvivid Backup & Migration” (over 800K active installations, developer wpvividplugins) ^[383];
• „BackWPup – WordPress Backup & Restore Plugin” (over 500K active installations, developer WP Media) ^[384].

Backup creation is often based on the widely known „3-2-1” rule, defined in 2009 by photographer P. Krogh. According to this practice, it is recommended to have at least three copies of data, stored on at least two different media, and at least one copy must be kept in a remote location outside the primary infrastructure, such as in cloud storage or a physical facility secured from malicious attacks and local incidents. Such diversification reduces the risk that all backups will be lost during a single incident ^{[385, 386, 387, 388, 389]}.

While the „3-2-1” method is well-known and frequently applied, it is not the only backup creation model. The extended „3-2-1-1-0” strategy additionally requires that at least one backup is stored offline or is set as immutable, ensuring that its data cannot be altered or deleted for a set period. Furthermore, this methodology emphasizes continuous backup quality control: copies must be regularly checked, and recovery processes must be tested to ensure data integrity and effective restoration without errors ^{[389, 390, 391]}. Thus, the „3-2-1-1-0” methodology strengthens data resilience against various incidents and reduces the risk of potential data loss. However, there is no one-size-fits-all solution, so every organization should formulate a backup policy considering its operational specifics and risk factors, while these models can provide a solid foundation for organizing this process.

When analyzing the backup creation process, it is important not only to determine the number of copies or the diversity of storage locations, but also to ensure their qualitative reliability. The first aspect is the completeness of backups. Merely initiating a copy process does not guarantee a reliable result, so it is necessary to verify whether the copy encompasses all essential site components: core files, the database, custom configurations, plugins, and themes. Although partial copies can be useful for quick data recovery, a full site restoration is only possible based on complete backups. In addition, it is necessary to continuously monitor the age of backups and apply a clear retention policy, as outdated copies can create a false sense of security. For instance, if a site is updated daily but the latest backup is a month old, such a discrepancy heightens the risk of partial data loss ^{[392, 393, 394, 395]}.

Another crucial aspect is backup storage and security. Copies should not be kept on the same server as the primary system, because potential vulnerabilities could grant unauthorized individuals access to the data. It is recommended to use geographically or technically isolated storage, regularly maintaining their technical condition, capacity, and network connection. This mitigates the risk of the copy process being interrupted or incomplete. Moreover, strict access control mechanisms must be implemented, allowing copies to be accessed only by authorized users. This control can be supplemented with data encryption to protect information from unauthorized appropriation or leakage ^{[392, 393, 394, 395]}.

Finally, the evaluation criterion for backups is their recoverability. A failed copy loses its practical value, so periodic test restorations in an isolated environment must be conducted, verifying not only the technical process but also system functionality post-recovery. Any flaw identified during testing must be analyzed and resolved. Practice shows that most errors only surface during restoration, so consistent and regularly conducted testing is a cornerstone of an organization’s data reliability and business continuity ^{[392, 393, 394, 395]}.

External Online Website Security Scanning Tools

External online website security scanning tools are typically browser-based automated solutions that allow for the identification of potential security flaws on a website. Their regular use provides significant benefits: it helps to spot vulnerabilities in a timely manner, such as outdated content management systems or plugin versions, insecure server configurations, SSL/TLS certificate errors, unauthorized redirects, or malicious code embedded into site content ^{[396, 397, 398]}. 

Because these tools operate in an external environment and do not require additional software installation on the server, their analysis is restricted solely to externally accessible information. This means they cannot identify server-side threats or more complex application-layer vulnerabilities. Despite these limitations, external online scanners remain valuable as a primary diagnostic measure helping to evaluate the overall security posture of a site.

One such external scanning tool, accessible via the website „site-check.nksc.lt”, is provided free of charge by the National Cyber Security Centre (NKSC). The check is executed in an automated manner utilizing the „OWASP ZAP” software and adhering to the „OWASP” methodology, oriented towards identifying known security flaws. The inspection results are delivered via a detailed vulnerability analysis report by email, allowing an assessment of the discovered gaps and the execution of consistent measures to bolster website security and reduce potential risks[399, 400].

Below are several significant external website security scanning tools capable of contributing to systematic website vulnerability assessment ^{[401, 402, 403, 404, 405, 406]}:

• „Sucuri SiteCheck” (https://sitecheck.sucuri.net)
• „HostedScan – OWASP Vulnerability Scan” (https://hostedscan.com/owasp-vulnerability-scan)
• „Barrion Scanner” (https://barrion.io)
• „HackerTarget – WordPress Security Scan” (https://hackertarget.com/wordpress-security-scan)
• „Quttera Website Malware Scanner” (https://quttera.com/website-malware-scanner)
• „Pentest Tools – WordPress Scanner” (https://pentest-tools.com/cms-vulnerability-scanning/wordpress-scanner-online-wpscan)

Long-Term Security Assurance

In conclusion, it can be stated that WordPress CMS security challenges primarily stem not from core vulnerabilities, but from the vast third-party component ecosystem, inadequate administration, and the application of improper security practices. The measures discussed in the article—from timely software updating, responsible component selection, strict access control based on strong passwords and multi-factor authentication, to technical system hardening using specialized security plugins, firewalls, or server-level configurations—form the foundation of multi-layered defense. An equally important aspect is the regular creation of backups and their reliable storage, ensuring business continuity after potential incidents.

However, even consistently implemented recommendations do not guarantee absolute security. The cyber threat environment is dynamic: new vulnerabilities constantly emerge and attack methodologies advance. Therefore, website protection must be perceived as a continuous, proactive process, encompassing activity log monitoring, periodic security audits, tracking relevant vulnerabilities in specialized databases, and continuously adapting security measures to shifting risks. Only such a holistic approach enables ensuring the long-term resilience of WordPress systems.