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.

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.

Progressively migrate the remaining images to modern formats, prioritizing the assets with the highest impact on initial loading.

Technical recommendations:

• Identify the JPEG/PNG/GIF images with the largest transferred size.
• Prioritize above-the-fold images, hero images, banners, carousels, content images, and category images.
• Convert suitable images to WebP or AVIF while preserving equivalent visual quality.
• Use the <picture> element when fallback support 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>
  

• If the site uses WordPress or another CMS/site platform, check whether the CMS, theme, optimization plugin, CDN, or image service supports automatic WebP/AVIF generation.
• Verify that the converted images are actually delivered in the final HTML or through the CDN, not only generated on the server.
• Keep PNG where it is technically justified, for example for complex transparency or specific graphic assets, but optimize file size.
• Review real displayed dimensions: avoid serving 2000 px images when they are displayed at 400 px.
• After migration, measure total page weight, LCP, and mobile loading behavior.

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.