Domain Risk HeatMap

Review the renewal process and confirm that the certificate will renew automatically.

Recommended checks:

1. Confirm renewal ownership

   • Identify whether renewal is handled by the hosting provider, CDN, DevOps team, agency, or internal administrator.
   • Make sure the responsible party is clearly assigned.

2. Validate automation

   • Check that automatic renewal is enabled.
   • Confirm that validation methods still work:
     • HTTP validation path is reachable.
     • DNS validation records can be updated.
     • CDN or proxy rules do not block certificate validation.

3. Check deployment path

   • Ensure the renewed certificate will be installed in the correct place:
     • Web server.
     • Reverse proxy.
     • CDN.
     • Load balancer.
     • Hosting control panel.

4. Monitor expiration

   • Set up certificate expiry alerts.
   • Recommended alert windows: 30, 14, 7, and 3 days before expiration.

5. Document fallback procedure

   • Keep access to the DNS provider and hosting/CDN panel available.
   • Document how to renew manually if automation fails.

Complete and standardize the HTTP-to-HTTPS redirect configuration.

Recommended checks:

1. Identify the incomplete case

   • Check whether the issue affects:
     • Apex domain.
     • www domain.
     • Specific paths.
     • Trailing slash variants.
     • Query strings.
     • Subdomains.
     • Redirect status codes.

2. Use permanent redirects

   • Use 301 redirects for production canonical URLs.
   • Avoid temporary 302 redirects unless there is a specific operational reason.

3. Preserve URL structure

   • Keep the same path and query string after redirect.
   • Avoid sending all HTTP requests to the homepage.

4. Remove redirect chains

   • Configure a direct redirect from HTTP to the final HTTPS canonical URL.
   • Minimize multiple hops across www, non-www, language paths, or trailing slash variants.

5. Apply rules consistently

   • Configure the redirect at CDN, proxy, load balancer, or web server level.
   • Avoid conflicting redirect rules between application, CMS plugins, hosting panel, and CDN.

6. Test common entry points

   • http://domain.com
   • http://www.domain.com
   • Important landing pages.
   • Key content/category pages.
   • Login and account pages.

7. Review HSTS only after fixing redirects

   • HSTS should be considered only when HTTPS works reliably across the intended hostnames.

Reduce unnecessary software version disclosure in HTTP response headers.

Recommended actions:

1. Identify the component exposing the version through the x-powered-by header.

   Example:

   curl -I https://example.com
   

2. Disable or minimize version disclosure.

   Nginx:

   server_tokens off;
   

   Apache:

   ServerTokens Prod
   ServerSignature Off
   

   PHP:

   expose_php = Off
   

3. If the header is generated by a framework, CMS, proxy, CDN, or plugin, remove or override the version at that layer.

4. Keep generic product disclosure only where operationally required.

   Prefer:

   Server: nginx
   

   Instead of:

   Server: nginx/1.18.0
   

5. Validate the result after deployment:

   curl -I https://example.com
   

6. Do not rely on header hiding as a security control. Also verify that the disclosed component is updated, supported, and not affected by known vulnerabilities.

Adopt modern image formats across the site, starting with the images that have the greatest performance impact.

Technical recommendations:

• Audit the current image weight and sort images by transferred size.
• Prioritize:
  • Main homepage or hero image.
  • Promotional banners.
  • Category images.
  • Main content images.
  • Carousels and visual modules loaded during the initial render.
• Convert suitable JPEG/PNG assets to WebP or AVIF using controlled compression.
• Keep JPEG/PNG fallbacks if additional compatibility is required:

  <picture>
    <source srcset="/image.avif" type="image/avif">
    <source srcset="/image.webp" type="image/webp">
    <img src="/image.jpg" alt="Image description">
  </picture>
  

• Configure automatic generation through the CMS, server, CDN, or deployment pipeline.
• Avoid uploading oversized images to the CMS.
• Use srcset and sizes to serve versions adapted to each viewport:

  <img
    src="/content-800.webp"
    srcset="/content-400.webp 400w, /content-800.webp 800w, /content-1200.webp 1200w"
    sizes="(max-width: 768px) 100vw, 50vw"
    alt="Content image description">
  

• Use loading="lazy" for non-critical images.
• Do not lazy-load the main image if it contributes to LCP.
• Measure before and after with Lighthouse, PageSpeed Insights, or WebPageTest to validate the real reduction in page weight and loading time.

Perform a browser-based consent review to confirm whether non-essential trackers load before user consent.

Recommended technical validation:

1. Open the page in a clean browser profile or incognito session.
2. Clear cookies, local storage and session storage before testing.
3. Open DevTools → Network.
4. Reload the page without interacting with the cookie banner.
5. Filter requests by known tracker domains, for example analytics, advertising, heatmap, session replay or remarketing providers.
6. Check whether any non-essential scripts, pixels, cookies or network calls are triggered before consent.
7. Repeat the test after accepting, rejecting and customising consent choices.

If non-essential trackers load before consent:

• Configure a Consent Management Platform (CMP).
• Categorise scripts by purpose: necessary, analytics, advertising, personalisation, functional.
• Block non-essential tags by default.
• Trigger analytics, advertising and remarketing tags only after the matching consent category is granted.
• Integrate the CMP with the tag manager, for example Google Tag Manager Consent Mode where applicable.
• Verify that consent withdrawal updates or deletes relevant client-side storage where technically possible.
• Document the final behaviour for legal/privacy review.

This technical fix should be validated by both a developer and the legal/privacy owner.

Review the heading structure and confirm whether multiple <h1> elements are intentional.

Recommended technical actions:

• Identify where each <h1> is generated: theme, CMS field, hero block, content component, header component or third-party widget.
• Keep one primary <h1> for the main page topic where possible.
• Convert secondary headings to <h2> or <h3> when they represent sections, blocks or supporting content.
• Ensure hidden, duplicated or responsive-only headings are not creating repeated H1s.
• Preserve a logical heading hierarchy for accessibility and document structure.
• Re-test key page templates after the change.

Complete the missing Open Graph tags inside the document <head>.

Recommended implementation:

<meta property="og:title" content="Page title for social sharing">
<meta property="og:description" content="Short, compelling description for social sharing">
<meta property="og:image" content="https://example.com/path/to/image.jpg">

Technical checks:

• Use an absolute URL for og:image.
• Recommended image size: at least 1200x630 px.
• Ensure the image URL returns HTTP 200.
• Ensure the image is crawlable and not blocked by authentication or robots rules.
• Keep og:title and og:description aligned with the visible page content.
• Use page-specific values for content pages, categories and landing pages.
• Ensure the tags are present in the initial HTML response.
• Test previews in major social and messaging platforms after deployment.

Provide an accessible name for every interactive link and button.

Recommended implementation:

<a href="/account" aria-label="View account">
  <svg aria-hidden="true">...</svg>
</a>

<button aria-label="Close dialog">×</button>

Technical checks:

• Prefer visible text content over aria-label when possible.
• For icon-only controls, add aria-label or visually hidden text.
• Ensure decorative icons inside the control use aria-hidden="true".
• Avoid generic labels such as "click here" or "read more" without context.
• Re-test with a screen reader or accessibility browser extension.

Publish a security.txt file with a clear vulnerability reporting process.

Recommended actions:

1. Create the file at the standard location:

   https://example.com/.well-known/security.txt
   

2. Include at least a valid contact method.

   Example:

   Contact: mailto:security@example.com
   Preferred-Languages: en, es
   Canonical: https://example.com/.well-known/security.txt
   

3. Optional but recommended fields:

   Policy: https://example.com/security-policy
   Acknowledgments: https://example.com/security-acknowledgments
   Expires: 2027-12-31T23:59:59Z
   

4. Make sure the contact mailbox is monitored.

5. Define an internal triage process:

   • Who receives the report
   • Who validates the issue
   • Expected response time
   • Escalation path for critical vulnerabilities
   • Criteria for coordinated disclosure

6. Verify publication:

   curl -I https://example.com/.well-known/security.txt
   curl https://example.com/.well-known/security.txt
   

Enable DNSSEC signing for the domain.

Recommended technical actions:

1. Confirm DNSSEC support with the current DNS hosting provider or registrar.
2. Enable DNSSEC signing on the authoritative DNS zone.
3. Publish the resulting DS record with the domain registrar so the parent zone can delegate trust.
4. Verify propagation and validate the chain of trust with an external DNSSEC validation tool.
5. Monitor key rotation schedules if the provider does not automate them.