My Security Upgrade Locked a Client Out of Editing Their Own Website

A client of mine came to me with a strange problem. The person who keeps their website up to date could still log in. They could still change other parts of the site. But the moment they tried to edit a regular page, the screen went blank except for one line: "This content is blocked. Contact the site owner to fix the issue." When I logged in and tried it myself, I got the same message.

The site owner was me, in a sense. Not long before, I had added a new layer of protection to all eight websites I manage. It is a set of instructions every visitor's browser receives, telling it exactly what the page is allowed to load and from where. Done right, it shuts the door on a whole family of attacks where a bad actor sneaks their own code onto your page.

Done slightly wrong, it shuts the door on you. That is what happened here. The protection was working perfectly. It was just protecting the site from its own editing screen.

How the System Works

• A Guest List for Every Page: Each time someone opens one of my sites, their browser gets a short list of approved sources for scripts, images, fonts, and embedded windows. Anything not on the list does not load.
• The Editor Lives in a Window Inside a Window: Modern page editors show your work inside a small inner window that the editor builds on the fly, right inside your browser. My guest list had no line for that kind of window, so the browser refused to show it. That was the blank screen.
• One Narrow Exception: I added a single entry allowing those on-the-fly inner windows. Only the page's own code can create one, so an outsider cannot use that opening to slip anything in.
• Three New Locks While I Was There: I also added three rules that were missing: no old-style plug-in content, no redirecting the page's base address, and a tighter rule on background helpers. The site ended up stricter overall, not looser.

Overcoming the Friction

1. The Easy Fix Was the Wrong Fix

The fastest fix would have been to switch the protection off for the whole admin area, the part of the site where the editing happens. That would have worked in about a minute. It also would have removed the protection from the most valuable part of the site, the part a hacker most wants to get into. I passed on it and tracked down the one specific line the editor needed instead.

2. Not Breaking the Checkout

One of the extra rules I considered would have limited where the site's forms are allowed to send information. That sounds like an obvious win. But this client takes payments online, and the checkout hands customers off to the payment company's own page. That rule could have quietly broken checkout. I left it out. A security rule that stops people from paying you is not a win.

3. Eight Sites With the Same Hidden Problem

Once my client's site was fixed, I checked the other seven sites. Every one had the same rule and the same blind spot. As far as I know, nobody had run into it there yet. I rolled the same fix out to all eight, then confirmed each one was actually sending the corrected rules to visitors instead of trusting that the change had saved.

The Business Win

• Back to Work the Same Day: My client could edit pages again that same day, without anyone rebuilding anything.
• Stronger, Not Weaker: Every site now has the editing fix plus three extra protections it did not have before.
• Seven Sites Fixed Ahead of Time: The other sites got the fix before anyone had to call me about a blank screen.

If you or your web person add security settings like this to your own site, test one thing right after: log in and try to edit a page. The next step on my end is adding that exact check to my routine, so the editing screen gets tested every time a security rule changes.

Curious what this looks like for something you need built? See more of these side by side on the case studies page.