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.

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 http://cursosfnn.com/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 http://cursosfnn.com/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.

Enable a modern HTTP protocol at the server, CDN or reverse proxy layer.

Recommended technical actions:

• Enable HTTP/2 on the HTTPS virtual host.
• Confirm that TLS configuration is compatible with HTTP/2.
• If a CDN is used, enable HTTP/2 and HTTP/3 support at the CDN edge.
• Check reverse proxy configuration if traffic passes through Nginx, Apache, HAProxy, Traefik or Cloudflare.
• Verify the negotiated protocol with tools such as:
  • curl -I --http2 https://example.com
  • browser DevTools network protocol column
  • external HTTP protocol testing tools
• Keep HTTP/1.1 available only as a fallback for older clients.

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.

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.

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.