A B grade is not a warning siren. It is a to-do list in the right order.

You ran a free security scan, got a B, and now you are staring at a list of findings with names like HSTS, DMARC, and Secure cookie flag. Nothing is on fire, but something clearly needs attention. This guide translates that list into plain order: what blocks visitors today, what lets others impersonate you, and what is hardening you can schedule with your developer.

A B grade means passable, not finished

The WardenBit Free Scanner grades sites A through E based on 40 or more automated checks of public signals. An A means the visible basics are in place. A B usually means the site works fine for visitors, but one or two trust controls are missing or incomplete.

In practice, B-grade reports cluster around the same handful of findings:

  • An SSL certificate that is close to expiring
  • HTTPS that works but without a strict redirect
  • A missing HSTS header
  • Email protections like SPF or DMARC that are only partly done
  • Cookies missing the Secure or HttpOnly flags

None of these means your site is breached. They mean small gaps an attacker could use to impersonate you, downgrade a connection, or piggyback on a session. An earlier WardenBit review of 10 public scans found the same pattern: the most useful signals were everyday gaps in email trust and browser hardening that accumulate quietly.

Why shop owners should care more than the grade suggests

A B does not stop checkout today. It raises the cost of the next bad day.

If your SSL certificate expires, browsers show a full-page warning and most visitors leave. (A truly expired certificate will usually drag the grade to a C or below, so on a B report this item is more often "expiring soon." Treat it as a countdown, not a false alarm.) When email authentication is incomplete, anyone can send mail that looks like your order confirmations or invoices. That does not compromise your website directly, but it lets someone borrow your brand for phishing, fake payment requests, and refund scams. Customers blame the name on the email, not the missing DNS record.

Missing HSTS and loose cookie flags work the same way. They do not hand over your admin panel by themselves. They make it easier for someone on the same network to downgrade a connection or steal a session where the flags are missing. OWASP describes HSTS as an opt-in header that tells browsers to use HTTPS only and to auto-upgrade future HTTP attempts, and to not let users click through certificate errors once HSTS is set. OWASP likewise notes that marking cookies HttpOnly keeps browser scripts from reading their values, which makes session theft through script injection harder, though it does not stop the underlying injection itself.

Think of a B as your shop passing inspection but leaving the back door on the latch. Fine on a quiet day, expensive on a busy one.

Fix in this order

You do not need to fix everything in one sitting. Work top to bottom. Rescan after each batch.

1. Anything that blocks visitors: SSL certificate and HTTPS redirect

If the report flags a certificate close to expiry, renew first. A lapsed certificate is the finding most likely to scare visitors away, because browsers show a full warning page instead of your store. (If your report shows an already-expired certificate, treat it as urgent regardless of grade. Most grading logic will already have dropped you to a C or below.) Renew through your host or certificate provider, then confirm the site loads over HTTPS without warnings and that HTTP addresses redirect to HTTPS.

How to confirm: open an http:// version of your homepage and check it lands on https:// without a warning. Ask your host to enable auto-renewal so this does not recur. Expiry monitoring is part of basic hygiene because the failure mode is so visible.

2. Anything that lets others impersonate you: SPF, DKIM, and DMARC

Next, close the impersonation gap. SPF lists which servers may send mail for your domain. DKIM adds a cryptographic signature. DMARC ties them together and tells receivers what to do with mail that fails. CISA describes enabling all three as a way to restrict initial access through mail sent on behalf of a domain the sender does not own.

This matters because your shop runs on email: order confirmations, shipping updates, password resets, invoices. To be precise about who requires what: Google and Yahoo have required SPF, DKIM, and DMARC since February 2024, but only for bulk senders (Google's line is roughly 5,000 messages a day to Gmail addresses). Microsoft followed in May 2025 with a similar 5,000-a-day threshold for mail to Outlook.com, Hotmail, and Live.com. If you send less than that, nobody will bounce your mail for missing DMARC. But these records are still the basic defense against someone sending mail as you, so they are worth having at any volume. If your scan shows SPF passing but DMARC missing, you are halfway there.

Ask your developer or email provider to publish a DMARC record and align it with your actual senders, including your store platform, help desk, and newsletter tool. One important warning: start with p=none, which only monitors. It does not stop anyone from impersonating you. Watch the reports for a week or two, confirm legitimate mail passes, then move to p=quarantine and finally p=reject. Only an enforced policy actually blocks fakes. Staying on p=none forever means the work is half done.

How to confirm: rescan and look for DMARC moving to the passing side, and send yourself test order mail to a major mailbox to check it does not land in spam.

3. Lock in HTTPS: HSTS

Once HTTPS and mail are solid, add HSTS. This is a single response header that tells browsers to always use the secure version of your site from then on. It prevents downgrade tricks where a visitor is silently pushed to the unencrypted version. OWASP documents it as an opt-in header for exactly this purpose.

Why not first? HSTS only helps once HTTPS itself is reliable, including all subdomains you care about. One caution before your developer turns it on: the strict options are hard to undo. includeSubDomains applies the rule to every subdomain, so a stray HTTP-only service (staging, help center, legacy shop) can break. And HSTS preload lists, once submitted to browser vendors, take months to leave. Start with a short duration on the main domain, increase it once nothing breaks, confirm every subdomain works over HTTPS before adding includeSubDomains, and hold off on preload until you are certain.

Last in the B-grade queue, ask your developer to mark session cookies with Secure and HttpOnly. Secure means the cookie only travels over HTTPS, which protects sessions against network eavesdropping. HttpOnly means browser scripts cannot read the value, which makes theft through injected scripts harder. Neither fixes insecure code by itself, but both shrink what a small flaw can become.

This is a good batch with your next routine maintenance window rather than an emergency change, since it touches login and cart behavior and deserves a quick test of checkout and account login after.

Send this to your developer

Copy the checklist below into an email. Fill in the bracketed parts.

Subject: Security scan follow-ups — [your site]

Hi [name],

Our security scan came back a B. Could you please work through
these in order?

1. Renew the SSL certificate and enable auto-renewal. Confirm
   http:// addresses redirect to https:// with no warnings.
2. Publish a DMARC record (start p=none, review the reports,
   then move to quarantine and finally reject). Confirm SPF
   and DKIM alignment for our senders: [store platform],
   [help desk], [newsletter tool].
3. Add HSTS with a short max-age first. Confirm every subdomain
   works over HTTPS before enabling includeSubDomains. No
   preload yet.
4. Mark session cookies Secure + HttpOnly (plus SameSite=Lax).
   Retest login, cart, and checkout after.
5. Next maintenance visit: review third-party scripts on payment
   pages, and tighten content security policy on staging first.

Thanks!

What you can schedule, not rush

Two common findings look scary and can wait for a planned visit. Third-party scripts without integrity controls and a missing full content security policy both expand exposure, but both are easy to break checkout with if rushed. Put them on the next developer visit: inventory which external scripts you actually use, remove what is stale, and then tighten policy. Do not let a B grade push you into editing payment-page scripts on a Friday afternoon.

If your report shows publicly reachable leftovers like environment files or version-control paths, move that up to batch one. Those are rarer on a B but worth immediate cleanup because they help reconnaissance and may leak credentials such as passwords or API keys. Remove or block the paths, rotate any secrets that might have been exposed, then rescan.

Putting a B in context

A B usually reflects a small number of missing controls, not a compromised site. The pattern repeats across public scans: email trust gaps and browser hardening gaps show up again and again as non-urgent findings, while certificate problems cause the most visible visitor impact. On the email side the direction is one-way. Mailbox providers have made authentication baseline for high-volume senders, and scanners flag its absence because impersonation is now one of the cheapest attacks to run against a small brand.

The practical takeaway is cadence, not panic. Fix the visitor-blocking item this week, the impersonation items this month, and the hardening items on your next maintenance cycle. Then rescan monthly. That steady rhythm is what turns a B into an A without drama.

Final takeaway

A B grade is your scanner telling you the shop is open and the locks mostly work. Fix what blocks visitors first, then what stops impersonation, then what locks in HTTPS and hardens sessions. Leave checkout-affecting cleanup for a planned visit. Rescan after each batch and monthly after that, and a B becomes an A without drama.

Is your site ready? Run a free security scan — 40+ automated checks, instant results, no commitment.

Related reading: