Website and Email Security Mistakes We Keep Seeing
July 2026
- 5 minute read
Security failures do not always begin with an attacker breaking through a firewall.
Sometimes, the door was already open.
A document was shared with anyone who had the link. A password was written into application code. A public endpoint was considered safe because only certain IP addresses were allowed. A plugin update was trusted without testing. Sensitive information was placed into an AI tool before anyone had established where that information could travel.
None of these decisions necessarily looks catastrophic in isolation. Most are made for convenience, speed, or because a control appears stronger than it really is.
That is what made them worth paying attention to in July.
Here are the five security mistakes we kept seeing throughout the month.
Mistake 1: Leaving Unused Administrator Accounts Active
Where this shows up
WordPress dashboards
Hosting control panels
Domain and DNS accounts
Business email platforms
Cloud services and supplier portals
How this happens
An employee changes role, a contractor finishes a project, or a supplier is replaced.
Their account is not removed because access revocation is assumed to be someone else’s responsibility. In other cases, a shared administrator account remains active because nobody knows which services still depend on it.
The account becomes part of the background and may remain untouched for years.
Why this causes damage
Every unused privileged account is another route into the organisation.
Its password may be old, reused, stored by a former supplier, or absent from current security reviews. If the account is shared, actions may not be traceable to one person. If nobody expects it to be used, suspicious activity may also go unnoticed.
Changing an employee’s email password does not automatically remove their access from every separate platform.
How to avoid this mistake
Give each administrator a named account
Remove access immediately when a role or contract ends
Review privileged accounts at regular intervals
Require multi-factor authentication
Avoid shared administrator credentials
Record who owns each account and why it exists
Mistake 2: Storing Passwords and Secrets in Code or Documentation
Where this shows up
Application source code
Configuration files
Deployment scripts
API documentation
Shared troubleshooting notes
Code repositories and copied project folders
How this happens
A developer needs an application to connect to an API, database, or another service.
The fastest option is to write the password, token, or connection string directly into the code or a configuration file. It works, the application is deployed, and the temporary shortcut becomes permanent.
Copies then spread through repositories, backups, developer computers, test environments, and documentation.
Why this causes damage
A secret stored in code is no longer held in one controlled location.
Anyone who can read the code may also be able to read the secret. Removing it from the current version does not necessarily remove it from repository history, backups, screenshots, exported files, or local copies.
If the same credential is reused across environments, one exposure may affect several systems.
Changing the code is therefore not enough. The exposed secret must be revoked or rotated.
How to avoid this mistake
Store secrets in a dedicated secrets manager
Use managed identities where supported
Separate credentials between production, testing, and development
Scan repositories for exposed secrets
Rotate credentials immediately after suspected exposure
Remove secrets from documentation and deployment instructions
Mistake 3: Keeping Backups in the Same Environment as the Live Website
Where this shows up
Backups stored on the same web server
Hosting snapshots within one provider account
Database exports left beside the live database
Website backup plugins using local storage
Copies kept under the same administrator credentials
How this happens
A website owner enables automatic backups and sees that new copies are created each day.
The backup files remain on the same server, inside the same hosting account, or under the same credentials as the live website. Because several restore points exist, the website appears protected.
The number of copies is not the problem. Their shared point of failure is.
Why this causes damage
If the server fails, the hosting account is suspended, ransomware encrypts the environment, or an attacker deletes its contents, the live website and its backups may disappear together.
Local backups can also consume storage until the server becomes unstable. Worse, a backup may appear successful for months without anyone confirming that it contains complete, usable data.
A backup only provides meaningful protection when it can survive the failure of the original system and be restored independently.
How to avoid this mistake
Keep at least one backup outside the live hosting environment
Separate backup access from daily administrator access
Encrypt backup copies
Retain more than one restore point
Monitor failed backup jobs
Test complete restoration regularly
Mistake 4: Updating Critical Website Plugins Without a Recovery Plan
Where this shows up
WordPress websites
E-commerce stores
Websites built with page builders
Reseller and payment integrations
Sites where plugins generate buttons, products, or page content
How this happens
A plugin update is available and appears routine.
It is installed directly on the live website without first confirming that a recent backup exists, testing compatibility, or recording which website functions depend on the plugin.
The website may still load after the update, but widgets disappear, links break, product pages stop working, or a critical error appears.
Why this causes damage
An update can change more than the visible plugin interface.
It may remove widgets, alter stored data, change shortcodes, introduce conflicts, or break integrations used throughout the website. Re-enabling the plugin may restore part of the site while leaving dependent content damaged.
Without a tested backup or staging copy, recovery becomes investigation under pressure.
Avoiding updates is not the answer either. Outdated plugins create their own security risk.
How to avoid this mistake
Maintain recent off-site backups
Test significant updates on a staging website
Record which pages and functions depend on critical plugins
Review the vendor’s changelog before updating
Check key pages, forms, products, and payment flows afterwards
Confirm that backups can actually be restored
Mistake 5: Assuming AI Training Controls Make Sensitive Prompts Private
Where this shows up
Public generative AI services
AI assistants connected to business accounts
Coding assistants used by developers
Documents uploaded for summarisation
Prompts containing personal, confidential, or customer information
How this happens
An AI service states that prompts will not be used to train its models.
Users interpret this as meaning that the information remains private or stays entirely within their organisation. Sensitive documents, source code, credentials, customer records, and internal discussions are then submitted without a clear approval process.
But training is only one possible use of the data.
Why this causes damage
Turning off training does not mean that a prompt never leaves the user’s environment.
The information may still be processed, transmitted, temporarily retained, logged, inspected for abuse, or handled by connected services and subprocessors according to the product and contract in use.
The exact path differs between providers, plans, features, and integrations. A consumer AI account, an enterprise AI service, and a privately deployed model should not be treated as though they provide the same controls.
Once sensitive information has been submitted to an unapproved service, the organisation may not be able to prove where it travelled, how long it remained there, or who could access it.
How to avoid this mistake
Approve AI services before business use
Classify information before placing it into a prompt
Prohibit credentials and highly sensitive personal data in prompts
Review contracts, retention terms, subprocessors, and data locations
Separate consumer and enterprise AI accounts
Log and govern AI use where sensitive business processes are involved
Conclusion
July’s five mistakes have different technical causes, but the same operational weakness: nobody tested what would happen when the normal process failed.
Would an old administrator account still work? Could an exposed credential be revoked without rebuilding the application? Would the backups survive the loss of the live server? Could a failed plugin update be reversed? Could the organisation explain where an AI prompt was processed?
Security is not established by the presence of an account review, a backup job, an update button, or a privacy setting. It is established by knowing that access can be withdrawn, systems can be recovered, secrets can be replaced, and sensitive information remains governed.
That requires ownership, verification, and periodic testing. Without them, a control may exist only on paper.
Many security problems begin quietly and remain unnoticed until something fails.
In July, we kept seeing five examples.
Mistake 1: Leaving Old Administrator Accounts Active
Where this shows up
Website dashboards
Hosting accounts
Domain accounts
Email and cloud services
How this happens
Someone leaves a project or changes role, but their administrator account remains active.
Nobody notices because the account is rarely used.
Why this causes damage
The old account remains another way into the system.
Its password may be outdated, reused, or still known by someone who should no longer have access.
How to avoid this mistake
Give every administrator a named account
Remove access when a role or contract ends
Require multi-factor authentication
Review administrator accounts regularly
Mistake 2: Writing Passwords into Code or Documents
Where this shows up
Application code
Configuration files
Scripts
Technical documentation
How this happens
A password or token is added directly to a file so that an application can connect to another service.
Why this causes damage
The secret may be copied into repositories, backups, developer computers, and old file versions.
Deleting it from the current file does not remove those copies.
How to avoid this mistake
Use a secrets manager
Use different credentials for each environment
Scan code for exposed secrets
Revoke and replace exposed credentials
Mistake 3: Keeping Backups Beside the Live Website
Where this shows up
Web servers
Hosting accounts
Website backup plugins
Database exports
How this happens
A website creates regular backups, but stores them on the same server or in the same hosting account.
It looks protected because several backup copies exist.
Why this causes damage
If the server or hosting account is lost, the website and its backups may be lost together.
A backup is useful only if it survives the failure of the original system.
How to avoid this mistake
Keep a backup outside the live hosting environment
Protect backup access separately
Monitor backup failures
Test that the website can be restored
Mistake 4: Updating Plugins Without Preparing for Failure
Where this shows up
WordPress websites
Online stores
Page builders
Payment and reseller plugins
How this happens
A plugin is updated directly on the live website without testing or checking the backup.
Why this causes damage
The update may break pages, widgets, buttons, products, or integrations.
The website may partly work while important functions remain broken.
How to avoid this mistake
Keep recent backups
Test important updates on a staging site
Check critical pages after updating
Confirm that backups can be restored
Mistake 5: Treating “Not Used for AI Training” as “Private”
Where this shows up
AI chat services
Coding assistants
Uploaded business documents
Prompts containing sensitive information
How this happens
Users see that training is disabled and assume that the prompt stays private.
Why this causes damage
The prompt may still leave the user’s environment and be processed, retained, logged, or handled by other services.
Different AI products provide different levels of protection.
How to avoid this mistake
Use only approved AI services
Do not place passwords or highly sensitive data into prompts
Check retention and processing terms
Use enterprise controls for business information
Conclusion
July’s mistakes remained hidden because normal operations continued.
Old administrator accounts still worked. Passwords remained inside files. Backups were never tested away from the live server. Plugin updates had no recovery plan. AI privacy settings were misunderstood.
Good security requires more than enabling a control. Access must be reviewed, backups must be restored, updates must be tested, secrets must be replaceable, and sensitive information must remain governed.
Need expert help protecting your environment?
Get Started