Domain Risk HeatMap

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.

Configure the following header on all relevant responses:

X-Content-Type-Options: nosniff

Technical checks:

• Ensure JavaScript files are served with a valid JavaScript MIME type.
• Ensure CSS files are served as text/css.
• Ensure JSON, images, fonts and downloadable files have correct Content-Type values.
• Apply the header consistently through the web server, CDN or reverse proxy.
• Re-test static assets and API responses after deployment.

Configure framing protection using Content-Security-Policy: frame-ancestors where possible, and optionally keep X-Frame-Options for legacy compatibility.

Preferred modern control:

Content-Security-Policy: frame-ancestors 'self'

Or, if the site must not be framed at all:

Content-Security-Policy: frame-ancestors 'none'

Legacy-compatible header:

X-Frame-Options: SAMEORIGIN

Or stricter:

X-Frame-Options: DENY

Technical checks:

• Use SAMEORIGIN if legitimate same-origin embedding is needed.
• Use DENY if the site should never be embedded.
• Do not use ALLOW-FROM; it is obsolete and ignored by modern browsers.
• If CSP frame-ancestors is already correctly configured, treat missing XFO as a lower-priority compatibility issue.
• Validate embedded widgets, admin panels, previews and embedded flows before enforcing DENY.

Configure an explicit Referrer-Policy header.

Recommended balanced option:

Referrer-Policy: strict-origin-when-cross-origin

Stricter option:

Referrer-Policy: no-referrer

Technical guidance:

• Use strict-origin-when-cross-origin for most commercial websites.
• Use no-referrer where maximum privacy is required.
• Avoid unsafe-url, because it can disclose full URLs to external destinations.
• Avoid placing sensitive data, tokens, emails or identifiers in URLs.
• Validate analytics, attribution and affiliate tracking before choosing a stricter policy.

Define a Permissions-Policy header that disables unused browser features and only allows required capabilities.

Example restrictive baseline:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), fullscreen=(self)

Adapt the policy to the site:

• Disable features not used by the website.
• Allow features only for self or specific trusted origins when required.
• Review embedded third-party content, including videos, maps, service widgets and marketing tools.
• Test user journeys that may require browser permissions.
• Document intentional exceptions.

Common directives to review:

• camera
• microphone
• geolocation
• payment
• usb
• fullscreen
• autoplay
• clipboard-read
• clipboard-write

Add a descriptive meta description inside the document <head>.

Recommended implementation:

<meta name="description" content="Concise description of the page, its value and its relevant context for users.">

Technical checks:

• Write a unique description for each important page.
• Keep it aligned with the visible page content.
• Avoid keyword stuffing or misleading claims.
• Avoid duplicate descriptions across many pages.
• Ensure it is present in the initial HTML response.
• For website pages, describe the content, category or commercial intent clearly.
• Re-test after deployment and cache purge.

Add a favicon file and declare it in the document <head>.

Recommended implementation:

<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

Technical checks:

• Use a square icon.
• Provide a high-resolution version, for example 48x48 px or larger.
• Ensure each favicon URL returns HTTP 200.
• Ensure the icon file is not blocked by robots.txt if search visibility is relevant.
• Confirm the declaration is present on the homepage and key templates.
• Check that the declared file is not returning an HTML error page.
• Purge CDN/cache after deployment.

Verify the robots.txt response directly.

Recommended technical actions:

• Request https://xufa.es/robots.txt directly in a browser and confirm it returns plain text, not an HTML page.
• Confirm the HTTP response status is 200.
• Confirm the Content-Type is text/plain.
• Ensure the file uses valid directives such as User-agent, Disallow, Allow and Sitemap.
• Check server, CDN or CMS routing rules that might intercept the /robots.txt path.
• Re-test after fixing the configuration.

Verify the sitemap response directly.

Recommended technical actions:

• Request https://xufa.es/sitemap.xml directly and confirm it returns valid XML, not an HTML error page.
• Confirm the HTTP response status is 200.
• Confirm the root element is <urlset> or <sitemapindex> with the correct namespace.
• Validate the XML structure with a sitemap validation tool.
• Check server, CDN or CMS routing rules that might intercept the /sitemap.xml path.
• Re-test after fixing the configuration.

Add resource hints for external font origins that participate in the initial page load.

Technical recommendations:

• Identify the real origin from which the font files are downloaded.
• Add preconnect in the <head> for critical font origins:

  <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>
  

• If the provider uses separate domains for CSS and font files, review both origins.
• For Google Fonts, the usual configuration is:

  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  

• As a lighter alternative, use dns-prefetch:

  <link rel="dns-prefetch" href="https://fonts.googleapis.com">
  

• Place the hints as early as possible inside the <head>.
• Avoid adding preconnect to too many domains. Use it only for origins that are genuinely required during the initial load.
• Review whether external fonts can be self-hosted to reduce third-party dependency.
• Use font-display: swap or an equivalent strategy to avoid invisible text while fonts are loading.
• Validate the result by measuring FCP, LCP, and visual text behavior during page load.

Manually verify whether a privacy policy exists and is easy to access from the analysed page.

Recommended technical actions:

1. Add a persistent footer link using clear wording such as:

   • Privacy Policy
   • Privacy Notice
   • Data Protection
   • Localised equivalents where appropriate, for example Política de privacidad.

2. Ensure the link is present in the initial HTML where possible, not only injected after user interaction.

3. Use a stable, crawlable URL, for example:

   • /privacy-policy
   • /privacy
   • /politica-de-privacidad

4. Confirm that the linked page returns HTTP 200, is indexable if appropriate, and is not blocked by authentication, geolocation or JavaScript-only navigation.

5. Manually review the legal content with the responsible legal/privacy team. This automated indicator only checks discoverability, not legal sufficiency.

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.

Manually verify whether the site provides the required legal and policy information for its jurisdiction and business model.

Recommended technical actions:

1. Check whether the following pages exist:

   • Legal notice / imprint / company information
   • Terms and conditions
   • Cookie policy
   • Privacy policy
   • Service, cancellation and policy information for the website, where applicable

2. Add persistent footer links using clear labels, for example:

   • Legal Notice
   • Terms and Conditions
   • Cookie Policy
   • Privacy Policy
   • Localised equivalents such as Aviso legal, Condiciones de venta or Política de cookies.

3. Ensure the links are:

   • Available from the homepage and relevant user-flow pages.
   • Present in the server-rendered HTML where possible.
   • Not hidden behind consent banners, modals or user-only areas.
   • Crawlable and returning HTTP 200.

4. Validate that each linked page is technically accessible:

   • No redirect loops.
   • No broken links.
   • No accidental noindex if visibility is required.
   • No blocking by robots.txt if search discoverability is desired.

5. Send the final legal content to the responsible legal/privacy team. This indicator only checks discoverability, not legal sufficiency.

Add the core 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 not blocked by authentication, hotlink protection or robots rules.
• Use page-specific metadata for content pages, categories, blog posts and campaigns.
• Keep Open Graph values consistent with the page title, meta description and visible content.
• Ensure the tags are present in the initial HTML response.
• Re-test link previews after deployment and cache purge.

Add relevant Schema.org structured data using JSON-LD.

Recommended implementation:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Brand Name",
  "url": "https://example.com"
}
</script>

Recommended schema types by page:

• Homepage: Organization, WebSite.
• Detail page: use schema types only when the corresponding data is real and visible.
• Category page: BreadcrumbList, optionally ItemList if appropriate.
• Blog or guide page: Article or BlogPosting.
• FAQ section: FAQPage only if the questions and answers are visible to users.
• Local business page: LocalBusiness when the business has a real physical presence.

Technical checks:

• Use JSON-LD where possible.
• Choose schema types that match the actual page content.
• Keep structured data consistent with visible content.
• Do not mark up fake reviews, unavailable items or hidden content.
• Validate the markup before deployment.
• Check eligibility with rich result testing tools where applicable.
• Ensure the JSON-LD is present in the initial HTML or reliably rendered for crawlers.
• Re-test after deployment and monitor Search Console for structured data errors.

Add semantic HTML5 landmarks to the page structure.

Recommended implementation:

<header>...</header>
<nav>...</nav>
<main>...</main>
<footer>...</footer>

Technical checks:

• Use exactly one <main> element per page for the primary content.
• Use <nav> for primary navigation menus.
• If semantic tags cannot be used, apply equivalent ARIA roles, for example role="main" or role="navigation".
• Avoid nesting landmarks of the same type without distinguishing labels.
• 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.