Website and Email Security Mistakes We Keep Seeing
January 2026
- 8 minute read
Each month, new security vulnerabilities are disclosed across plugins, platforms, and infrastructure components. Most are addressed through updates or mitigations, yet compromises continue to occur in environments where security tooling is already present.
In practice, these incidents are rarely caused by the vulnerability alone. They occur when implementation or operational assumptions allow an otherwise manageable issue to become exploitable. This series documents those recurring patterns. Vulnerabilities are referenced only where they illustrate why a specific mistake had operational impact.
Mistake 1: Assuming a CDN (Content Delivery Network) automatically protects the origin
Where this shows up
WordPress hosting environments
CDN and DNS configurations
Reverse proxy deployments
How this happens
In a typical deployment, a CDN is enabled to sit in front of a website, DNS is updated to point traffic through the CDN, and basic protections such as a web application firewall are activated. Origin access restrictions are often deferred, either because they require coordination with the hosting provider or because the site needs to remain accessible during testing.
Once the site is live, attention shifts elsewhere and the deferred restriction is never implemented. The origin server remains directly reachable via its IP address or an alternative DNS record, allowing requests to bypass the CDN entirely.
Why this causes damage
The issue was not missing a patch, but treating the CDN as an implicit enforcement layer and assuming protection without verifying that all traffic paths were constrained through it. When the origin remains reachable, CDN-level controls such as request filtering and rate limiting are irrelevant to an attacker.
How to avoid this mistake
Restrict origin access to CDN IP ranges
Block direct IP access at the firewall level
Test origin reachability outside the CDN after deployment
Treat CDN enforcement as a control that requires verification
Mistake 2: Leaving security controls in monitoring mode indefinitely
Where this shows up
Web application firewalls
Bot protection systems
Intrusion detection configurations
How this happens
Security controls are commonly deployed in monitoring mode to observe traffic patterns and identify potential false positives before enforcement. In many environments, no explicit timeline or ownership is defined for transitioning these controls to blocking mode.
As workloads evolve and priorities change, monitoring configurations persist indefinitely, resulting in malicious requests being logged but not acted upon.
Why this causes damage
The issue was not the absence of detection capabilities, but the absence of enforcement decisions and operational ownership. When monitoring modes remain enabled by default, exploit traffic is identified without being prevented, allowing known attack patterns to succeed.
How to avoid this mistake
Define monitoring mode as explicitly time-bound
Validate rules in staging or controlled environments
Assign responsibility for promoting rules to enforcement
Accept limited false positives as part of operational security
Mistake 3: Treating HTTPS as a security boundary
Where this shows up
Small business websites
Compliance-driven deployments
Legacy WordPress installations
How this happens
HTTPS is enabled to meet compliance expectations or baseline security requirements, after which additional application-level protections are deferred or omitted. The presence of encryption is treated as a sufficient indicator of security posture.
As a result, encrypted traffic is allowed to reach application endpoints without further validation or filtering.
Why this causes damage
HTTPS ensures confidentiality in transit but does not enforce application behavior or validate request intent. When encryption is mistaken for protection, vulnerable endpoints remain fully accessible to attackers, sometimes with reduced visibility for downstream inspection tools.
How to avoid this mistake
Implement and validate security headers
Apply request filtering and rate limiting
Monitor application behavior independently of transport security
Mistake 4: Deploying email authentication without enforcement
Where this shows up
Business email domains
Marketing platforms
SaaS-integrated email workflows
How this happens
Email authentication mechanisms such as SPF and DKIM are configured to satisfy baseline requirements or platform recommendations, while DMARC remains at policy none to avoid potential delivery issues. Aggregate reports are generated but not routinely reviewed.
Over time, this configuration remains unchanged, and domain abuse occurs without detection or intervention.
Why this causes damage
The issue was not the absence of authentication, but the absence of enforcement and monitoring. Without DMARC policy progression and report analysis, unauthorized use of the domain remains invisible until reputational or operational impact becomes apparent.
How to avoid this mistake
Progress DMARC beyond policy none
Review DMARC aggregate reports on a regular basis
Validate alignment across all authorized sending sources
Treat email authentication as domain protection rather than inbox filtering
Mistake 5: Retaining plugins without reviewing their exposure
Where this shows up
WordPress plugin ecosystems
Feature-driven site expansion
Third-party integrations
How this happens
Plugins are installed to support temporary features, testing, or one-time requirements, after which they remain enabled without further review. As sites evolve, the original purpose of the plugin becomes irrelevant, but the code remains reachable.
Over time, the cumulative attack surface increases without corresponding oversight.
Why this causes damage
The issue was not whether a plugin was actively used, but whether it was reachable. Installed plugins execute within the application context regardless of feature usage, making unused components viable entry points when vulnerabilities are disclosed.
How to avoid this mistake
Periodically inventory installed plugins
Remove unused or redundant components
Evaluate plugins based on exposure and privilege rather than popularity
Assign ownership for plugin lifecycle decisions
Closing observation
Across the issues described above, the common factor was not the presence of vulnerabilities or the absence of security tooling. In each case, controls existed but were either assumed to be effective by default, left unenforced, or implemented without ongoing verification.
These conditions are not the result of negligence, but of systems that allow partial implementations to persist indefinitely. When configuration, enforcement, and ownership are not explicitly defined and revisited, vulnerabilities become operationally relevant not because they are sophisticated, but because the environment allows them to be.
This pattern remains consistent across platforms and threat types and is unlikely to change without deliberate attention to how security controls are deployed, verified, and maintained over time.
Each month, new security vulnerabilities are disclosed.
Many are fixed quickly, yet incidents continue to happen.
In most cases, the vulnerability itself is not the main issue.
Incidents occur when assumptions or incomplete configurations allow an issue to be exploited.
This series documents those recurring patterns.
Vulnerabilities are mentioned only when they explain why a mistake had real impact.
Mistake 1: Assuming a CDN automatically protects the origin
Where this shows up
WordPress hosting environments
CDN and DNS configurations
Reverse proxy deployments
How this happens
A CDN is enabled in front of a website.
DNS is updated and basic protections are turned on.
Restrictions on direct access to the origin server are postponed.
This is often done to avoid delays or testing issues.
After launch, those restrictions are not revisited.
The origin server remains reachable through its IP address or another DNS record.
Why this causes damage
The issue is not missing updates.
The issue is assuming the CDN enforces protection by default.
If the origin server is reachable, CDN protections can be bypassed completely.
How to avoid this mistake
Allow origin access only from CDN IP ranges
Block direct IP access at the firewall
Test origin access outside the CDN
Verify that CDN enforcement is active
Mistake 2: Leaving security controls in monitoring mode indefinitely
Where this shows up
Web application firewalls
Bot protection systems
Intrusion detection configurations
How this happens
Security controls are deployed in monitoring mode.
This is done to observe traffic and reduce false positives.
No deadline is set to move to blocking mode.
No clear owner is assigned to make that decision.
Monitoring mode remains enabled for long periods.
Malicious traffic is logged but not blocked.
Why this causes damage
The issue is not lack of detection.
The issue is lack of enforcement.
When monitoring remains enabled, known attacks are allowed to proceed.
How to avoid this mistake
Set a clear time limit for monitoring mode
Test rules in staging or controlled environments
Assign responsibility for enforcement decisions
Accept limited false positives as part of security operations
Mistake 3: Treating HTTPS as a security boundary
Where this shows up
Small business websites
Compliance-driven deployments
Legacy WordPress installations
How this happens
HTTPS is enabled to meet basic security requirements.
Additional protections are postponed or omitted.
Encryption is treated as a sign of full protection.
Application-level controls are not added.
Why this causes damage
HTTPS only protects data in transit.
It does not validate requests or protect application logic.
Attackers can reach vulnerable endpoints over encrypted connections.
How to avoid this mistake
Implement and verify security headers
Apply request filtering and rate limiting
Monitor application behavior separately from transport security
Mistake 4: Deploying email authentication without enforcement
Where this shows up
Business email domains
Marketing platforms
SaaS-integrated email workflows
How this happens
SPF and DKIM are configured to meet requirements.
DMARC is left at policy none to avoid delivery risks.
Reports are generated but not reviewed.
The configuration remains unchanged over time.
Why this causes damage
The issue is not missing authentication.
The issue is missing enforcement and monitoring.
Unauthorized use of the domain remains undetected until damage occurs.
How to avoid this mistake
Move DMARC beyond policy none
Review DMARC reports regularly
Confirm alignment for all sending sources
Treat email authentication as domain protection
Mistake 5: Retaining plugins without reviewing their exposure
Where this shows up
WordPress plugin ecosystems
Feature-driven site expansion
Third-party integrations
How this happens
Plugins are installed for temporary needs.
They are not removed after the need passes.
Over time, unused plugins remain enabled.
The attack surface increases without review.
Why this causes damage
Whether a plugin is used does not matter.
If it is installed and reachable, it can be exploited.
Unused plugins still execute within the application context.
How to avoid this mistake
Review installed plugins regularly
Remove unused or redundant plugins
Evaluate plugins based on exposure and privilege
Assign ownership for plugin lifecycle decisions
Closing observation
Across these cases, the issue is not missing tools.
Controls exist but are assumed to work without verification.
When configuration, enforcement, and ownership are not clearly defined, partial implementations persist.
Vulnerabilities then become exploitable because the environment allows them to be.
This pattern is consistent across platforms and threat types.
It is unlikely to change without deliberate operational attention.
Need expert help protecting your environment?
Get Started