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.

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

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.

Add explicit Cache-Control headers to static resources.

Recommended technical actions:

• Configure cache headers for CSS, JavaScript, images, fonts and other static assets.

• For versioned assets, use:

  Cache-Control: public, max-age=31536000, immutable

• For non-versioned assets, use a shorter but explicit cache policy, for example:

  Cache-Control: public, max-age=86400

• Avoid applying aggressive caching to HTML documents unless the site has a safe cache invalidation strategy.

• Check server, CDN, reverse proxy and CMS plugin configuration.

• Validate the final headers with browser DevTools or curl -I.

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.

No urgent security remediation is required if HTTPS is working correctly.

Optional improvement:

1. Enable a minimal HTTP listener

   • Configure port 80 only to redirect traffic to HTTPS.
   • Do not serve website content over HTTP.

2. Use a permanent redirect

   • Redirect http://domain.com to https://domain.com.
   • Preserve the original path and query string.

3. Keep the attack surface minimal

   • Do not expose additional services on port 80.
   • Use it only for redirection and, if needed, controlled certificate validation.

4. Validate user access

   • Confirm that visitors typing the domain manually reach the HTTPS website.
   • Check old backlinks, bookmarks, and marketing URLs that may still use HTTP.

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.