Website and Email Security Mistakes We Keep Seeing
April 2026
- 7 minute read
April did not bring a wave of new vulnerabilities. Instead, it exposed something more persistent: environments that look secure at a glance, but fail under minimal pressure. Not because controls are missing, but because they are only partially implemented.
The difference is small on paper. In practice, it is where most incidents begin.
Mistake 1: Protecting the website with a CDN, but leaving the origin exposed.
Where this shows up.
WordPress websites behind a CDN such as Cloudflare.
Hosting environments with direct server IP access.
Applications using reverse proxies or load balancers.
How this happens.
A CDN is configured, and DNS is pointed correctly. WAF and bot protection are enabled.
The origin server remains publicly reachable because restricting access is treated as optional hardening, not as part of the deployment. In some cases, the origin IP is still visible through historical DNS records or misconfigured subdomains.
Why this causes damage.
Attackers do not need to bypass the CDN. They can avoid it.
If the origin is reachable, every control at the edge becomes less effective. The real security boundary shifts from the CDN to the exposed server.
How to avoid this mistake.
Restrict origin access to CDN IP ranges only.
Use authenticated origin pulls or private networking where possible.
Remove public exposure of backend servers entirely.
Mistake 2: Moving to DMARC reject without validating all senders.
Where this shows up.
Domains enforcing DMARC policies.
Email systems using multiple third-party senders.
Marketing, ticketing, or notification platforms.
How this happens.
DMARC is set to p=reject to prevent spoofing.
Not all legitimate sending services are aligned with SPF and DKIM. One platform is overlooked, often a low-visibility system such as alerts, invoices, booking emails, or automated notifications.
Why this causes damage.
Legitimate emails can be rejected.
There may be no attacker involved. The organisation disrupts its own communication flow while assuming it has improved security.
How to avoid this mistake.
Move gradually from monitoring to enforcement.
Validate SPF and DKIM alignment for every sender.
Use reporting to confirm behaviour before applying reject.
If you need visibility into how domains are configured at scale, tools such as a public DMARC mapping dataset can help benchmark your configuration against real-world deployments.
Mistake 3: Temporary firewall rules that never get removed.
Where this shows up.
Cloud environments using NSGs or security groups.
On-premises firewalls during troubleshooting.
Hybrid infrastructure with manual rule changes.
How this happens.
A rule is created to allow access during testing, deployment, or incident handling.
The task completes, but the rule remains. There is no expiry, no owner, and no follow-up review.
Why this causes damage.
Exposure becomes permanent without being intended.
Attackers do not need to exploit a complex vulnerability. They only need to find what was unintentionally left open.
How to avoid this mistake.
Assign an owner and expiry date to every exception.
Review firewall rules regularly.
Remove temporary access immediately after use.
Mistake 4: Treating CAPTCHA as a complete security control.
Where this shows up.
Contact forms and login pages.
Registration and password reset flows.
Public-facing APIs with basic protection.
How this happens.
Google reCAPTCHA or a similar CAPTCHA service is enabled and assumed to block automated abuse.
No additional controls are implemented. Rate limiting, behavioural detection, IP reputation checks, and abuse monitoring are not considered necessary.
Why this causes damage.
Modern bots can bypass or solve CAPTCHA challenges with minimal effort.
The control adds friction, but it should not be treated as complete protection.
How to avoid this mistake.
Combine CAPTCHA with rate limiting and behavioural controls.
Monitor abuse patterns instead of relying on a single barrier.
Apply layered bot mitigation strategies.
Mistake 5: Having monitoring in place without response ownership.
Where this shows up.
SIEM platforms and monitoring tools.
Cloud environments with alerting enabled.
Security dashboards with high alert volume.
How this happens.
Alerts are configured and generated correctly.
No clear responsibility exists for reviewing or acting on them. Over time, alerts become background noise.
Why this causes damage.
Detection without response has no operational value.
Incidents may be identified but not acted upon, allowing attackers to operate while warning signs already exist.
How to avoid this mistake.
Assign ownership for every alert category.
Reduce noise and prioritise actionable signals.
Define clear escalation and response procedures.
Closing pattern.
April did not highlight missing controls. It highlighted incomplete ones.
Security failures were not caused by absence, but by partial implementation.
If a control is not enforced consistently, it should be treated as unreliable.
These patterns are not isolated. Similar gaps continue to appear across previous analyses, particularly around authentication enforcement and email security misconfigurations.
April did not bring many new vulnerabilities.
Instead, it exposed something more common.
Systems that look secure at first glance
but fail under small pressure.
Not because security is missing
but because it is only partially implemented.
The gap is small
but this is where most incidents begin.
Mistake 1: CDN is enabled, but the origin server is still exposed
Where this shows up
Websites using Cloudflare or similar CDNs
Servers with direct public IP access
How this happens
The CDN is set up correctly.
But the origin server is still reachable from the internet.
Why this causes damage
Attackers do not break the CDN.
They go around it and hit the server directly.
This makes the protection ineffective.
How to avoid this mistake
Block direct access to the origin server
Allow only CDN traffic
Remove any public exposure
Mistake 2: DMARC is set to reject too early
Where this shows up
Domains using DMARC
Email systems with multiple tools
How this happens
DMARC is set to p=reject too soon
But not all systems are configured correctly
One sender is missed
Why this causes damage
Legitimate emails get blocked
No attacker is needed
The organisation disrupts its own email flow
How to avoid this mistake
Start with monitoring
Check all sending systems
Move to reject only when fully aligned
Mistake 3: Temporary firewall rules become permanent
Where this shows up
Cloud security groups
Firewalls during troubleshooting
How this happens
A rule is opened for testing
It is not removed
Why this causes damage
The system stays exposed
Attackers only need to find it
No exploit is required
How to avoid this mistake
Set an expiry for every rule
Review rules regularly
Remove access after use
Mistake 4: CAPTCHA is treated as full protection
Where this shows up
Login pages
Forms
Public APIs
How this happens
reCAPTCHA is enabled
No additional protection is added
Why this causes damage
Bots can bypass or solve CAPTCHA
It slows them down
It does not stop them
How to avoid this mistake
Add rate limiting
Monitor behaviour
Use layered protection
Mistake 5: Alerts exist, but no one acts on them
Where this shows up
SIEM tools
Monitoring dashboards
How this happens
Alerts are configured
But no one is responsible
Why this causes damage
Warnings are visible
But ignored
Attacks continue
How to avoid this mistake
Assign ownership
Reduce alert noise
Define response steps
Closing pattern
Security is often present
but not complete
If a control is not fully enforced
it should not be trusted
Need expert help protecting your environment?
Get Started