Domain Risk HeatMap

Endurece la política de forma progresiva:

1. Confirma que SPF y DKIM están bien configurados y alineados.
2. Activa los informes agregados (rua) y revísalos unas semanas.
3. Pasa de p=none a p=quarantine y finalmente a p=reject.

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 alt attribute to every content image.

Recommended implementation:

<img src="content-image.jpg" alt="Person speaking at a workshop">

Technical checks:

• Describe the image content or purpose concisely; avoid generic text such as "image" or "photo".
• Use alt="" (empty, not missing) for purely decorative images so screen readers skip them.
• Do not stuff alt text with keywords for SEO purposes.
• Re-test after deployment using a screen reader or accessibility browser extension.

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.

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.