BigCommerce Website Got Flagged as Malicious & How Code and Core Fixed It

BigCommerce Website with 1,000+ products got flagged as malicious and suspicious by security tools. Here’s the full story of how it happened, what was found, and how Code and Core fixed it.

A well-established North American BigCommerce store selling 1,000+ professional and consumer lighting products, from LED panels and floodlights to decorative fixtures, landscape lighting, and commercial systems.

And yet even a company this established, with this many products and this many customers, still got flagged as suspicious and phishing-related by multiple security services.

That’s the entire point of this case study: this can happen to anyone.

The Problem 

It began with a simple complaint: the website wasn’t loading on desktop. The browser was throwing an ERR_CONNECTION_RESET error, which sounds scary and usually means something is wrong at a very basic level (like DNS, SSL, or the server itself). But as the investigation unfolded, the real picture was more nuanced 

Quick Fact: ERR_CONNECTION_RESET is one of the most misleading browser errors. It can mean a server is down, but it can equally mean a local firewall, antivirus, or endpoint security tool is quietly blocking the connection before it even leaves your machine.

Browser shows ERR_CONNECTION_RESET, but is it really?

The same site opens perfectly on a mobile device using a personal mobile network. Even on the office internet, the mobile device could open the site. So the internet connection wasn’t the problem. Even when the office desktop switched to mobile internet, it still couldn’t open the site. The problem was the machine itself.

The antivirus/endpoint protection software on the office computer had blacklisted apollolighting.com  and was silently blocking it, not the internet, not the DNS, not BigCommerce.

Security is not a product, but a process. It’s not something you buy and forget; it demands ongoing attention at every layer of your digital presence.

~ Bruce Schneier, Security Technologist & Author

The Investigation

Step-by-Step: How the Problem Was Diagnosed

Code and Core team ran a structured diagnostic, checking each possible cause one by one until they found the real reason.

Step 1: Check the Connection Error

The browser showed ERR_CONNECTION_RESET. This usually means something is blocking the connection, like a firewall, an SSL problem, or a security software flag. This became the starting point of the investigation.

Step 2: Review DNS and Domain Settings

The team checked BigCommerce DNS and domain configuration. BigCommerce nameservers were active, the root domain pointed correctly to 63.141.128.8, and www.apollolighting.com  resolved correctly as a CNAME. DNS was fine with no issues.

Step 3: Review 1,007 URL Redirects

The redirect file was exported and reviewed. Out of 1,007 total redirects (900 manual + 107 dynamic), the team found problems: 

1 duplicate redirect for /i, 27 self-redirects (a URL redirecting to itself is completely pointless), 4 broken redirects with a target value of 0, and 5 redirects pointing to another domain: apollolandscapelighting.com. 

These didn’t break the site, but they made the redirect profile look untidy, which makes security scanners suspicious.

Step 4: Isolation Test (The Most Important Step)

The team tested the website across different devices and networks to understand exactly where the block was coming from. 

See the exact results in the table below.

Device	Network	Result
Office desktop	Office WiFi	Site did not open
Mobile phone	Personal mobile data	Site opened fine
Mobile phone	Office WiFi	Site opened fine
Office desktop	Personal mobile data (hotspot)	Still did not open

What this tells us: The problem was not the internet connection. The mobile worked fine on both networks. The problem was the office desktop itself; specifically, Norton (the antivirus/security software installed on it) was blocking the site because it had already flagged apollolighting.com  as suspicious.

Tip: Always test from multiple devices and networks before assuming your site is down. If mobile data works but the office desktop doesn’t on any network, the problem is the machine, not the website.

Step 5: VirusTotal Scan

The team scanned the site on VirusTotal, a service that checks your URL against 95 different security vendors at once. 

Result: the site was loading normally (HTTP 200), but 1 out of 95 vendors, ADMINUSLabs, had flagged it as malicious. 

Just 1 vendor is enough to cause Norton to block the site.

Step 6: Quttera Deep Scan (The Turning Point)

Quttera goes inside your website files, not just the URL. 

This scan found 3 critical things: a reference to blacklisted domain searchserverapi1.com  inside the storefront, an unconditional redirect firing on page load, and external scripts from wisepops.net.  This shifted the entire investigation toward storefront code. 

Quttera finding	Type	Risk level
Reference to searchserverapi1.com	Blacklisted domain	High
Unconditional redirect on page load	Suspicious behavior	High
External scripts from wisepops.net	Third-party script	Medium

Root Cause Analysis

What Was Actually Living Inside the Website?

Once the team started digging into the BigCommerce storefront’s code, in the actual files that make the website run, they found several issues. None of these were signs of a hacker breaking in. They were more like digital clutter that had built up over time: old scripts, test code left behind, and poor security practices that looked suspicious to automated scanners.

• Suspicious External Scripts: The site was loading scripts from third-party domains like wisepops.net, cloudfront.net blocks, and NoFraud device checkers, some no longer needed.
• Login Data Stored Insecurely: A custom “Remember Me” login feature was storing sensitive login information in the browser’s LocalStorage, a practice that security tools flag as risky.
• Test Code Left in Production: A GraphQL testing script had been added to the main layout file during development and was never removed before going live.
• Messy Redirect Profile: 1,007 redirects total, including 27 that pointed back to themselves (self-redirects), 4 broken ones, and 5 pointing to another domain entirely.
• Legacy & Outdated Scripts: Scripts like Searchanise, GeoTrust SSL table blocks, and a show/hide password icon were still loading, serving no real purpose but adding noise.
• Hardcoded Scripts in Theme: Some scripts were hardcoded directly into the theme files, meaning they couldn’t be seen or removed through normal Script Manager tools.

Warning:  Storing login data in browser LocalStorage is a serious security anti-pattern. LocalStorage is readable by any JavaScript on the page including third-party scripts. If any one of those scripts is ever compromised, login credentials can be silently stolen.

The redirect problem

1,007 redirects: the messy profile visualized

Self-redirects and broken redirects don’t crash a site. But they create a messy redirect profile that signals poor maintenance to reputation scanners, and that alone can be enough to raise suspicion.

The Fix

The team did not delete anything blindly. Every script was investigated individually, understanding what it does, who added it, and whether removing it would affect the business before taking any action.

• Script Manager Full Audit: Every active Script Manager entry was reviewed one by one. Scripts were separated into “safe to keep,” “needs correction,” and “should be removed.”
• Footer Script Cleanup: 5 items removed from footer-level scripts: Searchanise, GeoTrust SSL block, NoFraud device check, cloudfront block, and show/hide password script.
• Theme File Deep Dive: Not all scripts are visible in the dashboard. The team went into the actual theme files base.html and theme partials to find and remove hardcoded scripts.
• LocalStorage Code Removed: The “Remember Me” login code was removed from halo-side-block.html. This eliminated the phishing-like browser storage behavior.
• Facebook Pixel Validated: The Facebook Purchase tracking was reviewed and confirmed: it was correctly set up for order confirmation only — not a site-wide issue. The misconfigured Add to Cart line was corrected.
• Redirect File Cleaned: 27 self-redirects removed, 4 broken redirects fixed, 1 duplicate removed. The redirect profile was made clean and logical.
• Console review: Browser console errors were reviewed and cleaned up by removing or fixing unnecessary script issues, resulting in a smoother storefront experience.

An Important Isolation Test: {{{footer.scripts}}}

During the investigation, the team disabled BigCommerce’s {{{footer.scripts}}} to test if the problem came from that source. The Norton blocking persisted even after this. That told them the issue was not in BigCommerce-managed footer scripts — it was in hardcoded theme files that exist outside the Script Manager completely.

This is a very important discovery: on BigCommerce, some scripts are hardcoded directly in theme HTML files (like base.html and referenced partials including components/common/header, components/common/footer, and components/halothemes/global/halo-global). These scripts are invisible from the Script Manager dashboard. You have to go into the actual code to find and remove them.

Submitting Disputes to Security Vendors

Cleaning the code was only half the battle. Security vendors don’t automatically re-scan your site the moment you fix something. You have to tell them you’ve fixed it and ask them to review again. Here’s what was submitted:

1. Norton Safe: Web Dispute Filed

A detailed cleanup summary and supporting context were submitted through Norton’s review portal. Norton later confirmed by email that apollolighting.com  had been removed from their suspicious database.

2. Quttera: Review Request Emailed

The Quttera team was contacted directly by email asking for a fresh scan and blacklist removal after remediation.

3. ADMINUSLabs: Dispute Raised via VirusTotal

Since ADMINUSLabs was the one vendor out of 95 that had flagged the site as malicious, a review request was raised specifically for their classification.

Important takeaway:  Even after you clean your site, reputation databases take time to update. Proactively filing disputes speeds up the process significantly, sometimes from weeks to days.

The Results

After the Cleanup: What the Scans Say Now

After all remediation actions were complete, the team ran verification scans across multiple security services. The results were clear:

Summary: The storefront is now in a significantly cleaner and lower-risk state. All seven tools checked after cleanup either showed the site as safe or confirmed the previous flag had been removed. Norton confirmed the removal by email.

6 Things Every Online Store Owner Should Do Right Now

BigCommerce compnay didn’t do anything malicious. Nobody hacked them. Their site was flagged because of accumulated technical debt: old scripts, test code left in production, bad security practices in theme files, and outdated third-party tools. This can happen to any store, any size.

• Audit your scripts at least once every 3 months: Every third-party script you add is a potential red flag for security scanners. Review your Script Manager. Remove anything you’re no longer using: Wise Pops, NoFraud, Searchanise, old tracking scripts. If you don’t know what a script does, find out or remove it.
• Never store login data in LocalStorage: Convenient “Remember Me” features that write login values to the browser’s LocalStorage look like phishing behavior to security scanners. Always use secure, server-side session management instead.
• Remove all test and debug code before it goes live: A GraphQL testing script, a temporary debug logger, a test API call these all look suspicious on a live production website. Create a checklist that your development team runs before any code goes to production.
• Clean up your redirects regularly: 27 self-redirects and 4 broken redirects may not crash your site, but they signal to security scanners that something is wrong with your site’s link management. Review and clean redirects at least once a year.
• Monitor your reputation proactively:Don’t wait until your employees can’t open your own website. Check your domain regularly on VirusTotal, Quttera, Norton Safe Web, and Bitdefender. These tools are free and take less than 5 minutes to run.
• Understand what’s in your theme files, not just Script Manager: On BigCommerce (and most platforms), scripts can be hardcoded directly in theme HTML files like base.html and its partials. These are invisible from the dashboard. If you’ve had multiple developers work on your store, get a full theme file audit done.

 

It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you’ll do things differently.

~ Warren Buffett