Website and Email Security Mistakes We Keep Seeing
September 2026
- 10 minute read
September’s recurring security mistakes shared one idea: teams checked the most visible layer and assumed it represented the whole risk.
A domain looked almost right. An AI agent received all the access it might need rather than the access required for one task. A phishing page opened after a trusted redirect. A supplier was assessed while its critical dependencies remained unseen. A system stayed available while someone quietly accessed its data.
Security decisions improve when teams look beyond the first reassuring signal. That means checking the exact destination, limiting what automated systems can do, mapping who sits behind a service and monitoring what happens even while everything appears to work.
Here are five website and email security mistakes we kept seeing in September.
Mistake 1: Trusting a Domain Because It Looks Correct
Where this shows up.
Email sender addresses
Website login pages
Payment and renewal requests
Search results and online adverts
Links shared through messages and documents
How this happens.
People recognise a brand by its overall shape and colour before they inspect every character in its domain. Attackers take advantage of that habit with lookalike domains.
Some substitutions are simple, such as using a zero in place of the letter O. Others use characters from different writing systems that look almost identical in common fonts. Attackers also use extra words, misleading subdomains and letter combinations that are easy to misread on a small screen.
The page can still use HTTPS and display a padlock. That confirms an encrypted connection to the domain shown in the browser. It does not confirm that the domain belongs to the organisation the page is imitating.
Why this causes damage.
A convincing lookalike domain can capture usernames, passwords and payment details. It can also distribute malware or redirect visitors through several pages before reaching the final lure.
The visual similarity makes the attack difficult to spot at a glance. Mobile screens may hide part of the address, while email applications often emphasise a display name instead of the complete sender address.
CISA describes the registration of lookalike domains, including internationalised domain homograph attacks, as infrastructure used by threat actors for malicious operations.
How to avoid this mistake.
Open important services from a saved bookmark or a known application rather than from an unexpected message. A password manager can add another useful signal because it fills credentials only on the domain where they were saved.
Make the full sender address and destination domain visible in security training. Teach people to pause when a message creates urgency around sign-in, payment or account recovery.
Organisations with frequently impersonated brands should monitor for suspicious domain registrations and establish a rapid process for reporting and taking down confirmed copies. Browser protection, DNS filtering and email controls add further layers when visual inspection fails.
Mistake 2: Giving an AI Agent More Access Than Its Task Requires
Where this shows up.
Customer-service and shared-inbox agents
Content publishing and website administration
Cloud, identity and security automations
Finance, CRM and document workflows
Coding assistants connected to repositories or deployment tools
How this happens.
An AI agent needs access to tools and data before it can complete useful work. During a fast deployment, the easiest route is often a broad service account, a collection of powerful API scopes or a copy of the permissions held by the person testing it.
The agent may receive permission to read every mailbox when it needs one folder, publish across an entire website when it needs a draft queue, or change cloud resources when its task only requires a status check. Several agents may also share one identity, making their actions difficult to separate.
OWASP describes this pattern as excessive agency. The risk grows when excessive functionality, permissions or autonomy allow an unexpected, ambiguous or manipulated model output to trigger a real action.
Why this causes damage.
An AI error becomes a security incident when the agent can act on it. A malicious instruction hidden in an email, web page or document may influence the agent to send information, alter content, create accounts or call an unintended tool.
Broad permissions increase the possible damage. Shared credentials weaken attribution, while long-lived secrets give an attacker more time to reuse access. High-speed automation can repeat the same harmful action across many records before a person notices.
How to avoid this mistake.
Give every agent its own identity and grant only the tools, data and actions required for its defined task. Prefer read-only access, narrow scopes, allowlisted destinations and short-lived credentials.
Require human approval for high-impact actions such as sending external messages, publishing content, changing permissions, deleting data or moving money. Keep development and production access separate, and place sensible limits on volume, cost and repetition.
Record the instruction, tool call, target, result and approving identity in a protected audit trail. Test how the agent responds to hostile content and unclear requests before expanding its autonomy.
Mistake 3: Assuming Phishing Needs a Suspicious Website
Where this shows up.
Document-signing notifications
Microsoft and Google redirects
Browser tabs opened from email links
Blob URLs and locally rendered pages
Embedded frames and browser service workers
How this happens.
Traditional phishing detection often focuses on the reputation of the website hosting the final page. Modern browser-based attacks can blur that boundary.
Barracuda documented a September campaign in which a message led through legitimate Microsoft infrastructure before the browser assembled the phishing content locally. The final page used a blob URL, which points to data held in the browser’s memory rather than to a conventional public web page.
The navigation begins with something familiar. The malicious content appears later, after redirects and browser-side code have done their work.
Why this causes damage.
An initial link may pass a basic reputation check because it belongs to a trusted service. The final content can be temporary, personalised and difficult for a scanner to retrieve in advance.
Users may also see a recognised Microsoft address during part of the journey and assume that trust carries through to every later page. Once the browser renders the lure, it can imitate a sign-in screen and send captured details to an attacker-controlled service.
How to avoid this mistake.
Inspect the full redirect chain and the behaviour of the rendered page, rather than judging only the first URL. Combine email filtering with browser, DNS, identity and endpoint signals so one trusted hop cannot decide the outcome.
For unexpected document or account alerts, open the service directly from a bookmark or application and find the item there. Treat unusual blob: addresses, repeated redirects and fresh sign-in prompts as reasons to stop and verify.
Security teams should test whether their controls can analyse pages created inside the browser and alert on credential submissions to unapproved destinations.
Mistake 4: Assessing the Supplier but Missing the Dependency Chain
Where this shows up.
Website hosting and content delivery
Email, identity and collaboration platforms
Payment, analytics and customer-support services
Managed IT and security providers
Backup, recovery and software supply chains
How this happens.
An organisation reviews its direct supplier, signs a contract and records the service as assessed. The review stops there, even though the supplier relies on cloud hosting, identity services, support platforms, software components and subcontractors of its own.
Those dependencies may store customer data, hold privileged access or keep the service available. They can also change after the original procurement review, while the customer’s supplier record still shows the same reassuring status.
The NCSC advises organisations to build a clear picture of suppliers, establish their subcontractors and understand the dependencies that support essential services. The immediate supplier is only the first link in that picture.
Why this causes damage.
A weakness or outage several layers down can interrupt the service, expose data or undermine a security control. The organisation may have no direct relationship with the affected provider and limited visibility of what happened.
Hidden concentration creates another risk. Several apparently independent suppliers may depend on the same cloud, identity or software provider, turning one incident into a wider business disruption.
Incident notification can also slow as information moves through multiple contracts. By the time the customer receives a useful update, its own investigation and communication deadlines may already be under pressure.
How to avoid this mistake.
Map the dependencies behind every critical service. Record which parties can access data or systems, which services they rely on and what business process would stop if one became unavailable.
Set proportionate contract requirements for security, subcontractor oversight, material changes, audit evidence and incident notification. Review critical suppliers throughout the relationship rather than treating due diligence as a one-time event.
Look for shared dependencies across the supplier portfolio. Test how the organisation would communicate, recover and move to an alternative if a critical provider or subprocessor failed.
Mistake 5: Using Uptime as Evidence That No Breach Occurred
Where this shows up.
Website administration systems
Customer and case-management portals
Cloud file repositories
Email and document platforms
Business applications containing sensitive records
How this happens.
Security incidents are often pictured as outages, ransomware screens or visibly broken systems. That makes availability an easy but incomplete health check: the service works, so the organisation assumes the service is safe.
Quiet data access creates a different picture. In a September disclosure concerning Thomson Reuters’ C-Track court-management platform, the company said an unauthorised party obtained certain files in March. The activity was identified later, while the affected systems reportedly continued operating.
The absence of disruption can be exactly what an attacker wants. Reading or copying information attracts less attention than changing or encrypting it.
Why this causes damage.
Uptime measures availability. It says little about who accessed the data, what they downloaded or whether a privileged account behaved normally.
A service can respond to every customer request while sensitive records leave through an authorised-looking session. If monitoring focuses on errors and downtime, the organisation may discover the incident through an external report or a later investigation.
How to avoid this mistake.
Monitor access as well as availability. Look for unusual exports, bulk downloads, new access locations, unexpected privileged sessions and activity outside normal working patterns.
Keep audit records protected and searchable, with enough retention to investigate activity discovered months later. Apply least privilege to sensitive repositories and review accounts whose access has expanded over time.
Test alerts with realistic data-access scenarios. A useful exercise should prove that the team can detect and investigate quiet collection, even when the website or business application continues working normally.
Conclusion
September’s five mistakes came from treating one visible signal as the complete picture.
A correct-looking domain can belong to an attacker. A useful AI agent can hold more power than its task requires. A trusted redirect can end at content assembled inside the browser. An assessed supplier can rely on unseen providers. A working system can still be losing data.
The practical lesson is to follow the whole path. Verify the destination, constrain every identity, inspect redirects, map dependencies and monitor access alongside availability.
September’s biggest security mistakes came from checking only the visible layer.
That can mean trusting a familiar domain, giving an AI agent broad access, missing the final page behind a redirect, overlooking a supplier’s dependencies or watching uptime while data is accessed.
Here are the five mistakes and the practical response to each one.
Mistake 1: Trusting a Domain Because It Looks Correct
Where this shows up.
This appears in email addresses, login links, payment requests and search results.
How this happens.
Attackers register domains that look like a real brand. They swap similar characters, add extra words or hide the important part of the address on a small screen.
A padlock shows that the connection is encrypted. It does not prove who owns the website.
Why this causes damage.
A lookalike website can steal passwords, payment details or personal information. It can also deliver malware.
How to avoid this mistake.
Use a saved bookmark or known application for important services. Let a password manager help check the exact domain.
Pause when a message creates urgency. Read the full sender and website address before signing in or paying.
Mistake 2: Giving an AI Agent More Access Than Its Task Requires
Where this shows up.
This appears in inbox, website, cloud, finance and coding agents.
How this happens.
An AI agent needs access before it can complete a task. Teams sometimes give it a broad service account or copy a person’s permissions because that is quick.
The agent can then read, change or send much more than the task requires.
Why this causes damage.
An error or hidden malicious instruction can trigger a real action. Broad access makes the possible damage much larger.
How to avoid this mistake.
Give each agent its own identity and the smallest set of permissions it needs. Use short-lived credentials and read-only access where possible.
Require a person to approve high-impact actions. Log every instruction, tool call, target and result.
Mistake 3: Assuming Phishing Needs a Suspicious Website
Where this shows up.
This appears in document alerts, redirects, browser tabs and locally created web pages.
How this happens.
A link can begin on a trusted service. The browser can then build the phishing page in its own memory using a blob URL.
Why this causes damage.
Basic scanners may see the trusted first step instead of the final lure. The temporary page can still copy a real sign-in screen and steal details.
How to avoid this mistake.
Open unexpected document or account alerts through the service’s normal application or bookmark. Stop when a link passes through several redirects or opens another sign-in page.
Security controls should inspect the whole journey and page behaviour, not only the first link.
Mistake 4: Assessing the Supplier but Missing the Dependency Chain
Where this shows up.
This appears in hosting, email, payments, managed IT, backups and software services.
How this happens.
The organisation checks its direct supplier. It misses the cloud services, subcontractors and software providers behind that supplier.
Those dependencies may change after the first review.
Why this causes damage.
A failure several layers down can expose data or stop a critical service. Several suppliers may also depend on the same hidden provider.
How to avoid this mistake.
Map the providers behind each critical service. Record their access, data, dependencies and effect on the business.
Set rules for subcontractors, changes and incident notifications. Review critical suppliers throughout the relationship.
Mistake 5: Using Uptime as Evidence That No Breach Occurred
Where this shows up.
This appears in websites, cloud storage, email systems and business applications.
How this happens.
Teams look for outages or ransomware. If the service still works, they assume everything is safe.
An attacker may prefer to copy information quietly.
Why this causes damage.
Uptime only shows that a service is available. It does not show who accessed the data or what they downloaded.
How to avoid this mistake.
Monitor unusual downloads, exports, access locations and privileged sessions. Keep audit records long enough to investigate activity found months later.
Test whether the team can detect quiet data collection while the service continues to work.
Conclusion
The visible layer is only part of the risk.
Check the exact domain, limit every agent, follow redirects, map supplier dependencies and monitor data access even when systems keep working.
Need expert help protecting your environment?
Get Started