Auditoría de seguridad de una cuenta publicitaria

Una auditoría de tráfico y seguridad debe proteger a usuarios, anunciantes y disponibilidad del sitio sin convertir señales incompletas en acusaciones. Un pico de visitas, un user-agent sospechoso o un CTR que cambia no prueban por sí solos un ataque ni invalidan una cuenta. La respuesta sólida conserva evidencias, compara segmentos y modifica controles de forma acotada y reversible.

1. Tráfico inválido: GIVT y SIVT

Investiga señales de tráfico inválido con evidencias y controles acotados. Un pico de visitas, un user-agent o un CTR cambiante no prueban por sí solos fraude ni una infracción.

La terminología GIVT/SIVT sirve para entender por qué un filtro por IP no resuelve el problema completo. La referencia normativa aplicable es el documento de actualización IVT del MRC. En AdSense, la cobertura de una señal de tráfico no equivale a una prueba sobre un evento individual.

2. Cómo investigar un pico de CTR o un presunto click bombing

Un CTR anómalo merece análisis, pero no existe un umbral fijo —por ejemplo, “más de 10%”— que diagnostique fraude para cualquier sitio, formato y volumen. Separa clicks e impresiones por día, URL, unidad, país, dispositivo y fuente de adquisición, y compáralos con una línea de base del mismo día de semana y periodo estacional. Revisa si aumentaron impresiones, visitas, formularios, errores 4xx/5xx o tráfico de una campaña a la vez.

Los access logs registran peticiones a páginas y recursos del editor; normalmente no son un registro de los clics que los usuarios realizan dentro de un iframe publicitario de otro dominio. Por eso no se debe unir una dirección IP con un clic de AdSense ni afirmar “este visitante hizo clic” a partir de una solicitud del servidor. El análisis sirve para detectar un patrón de acceso hostil, documentar contexto y decidir si se limita una ruta propia, no para reemplazar la medición de Google.

Conserva una copia acotada de logs, la zona horaria, intervalo analizado, URLs afectadas y cambios de campañas o etiquetas. Evita publicar IP o IDs de usuario; limita retención y acceso de acuerdo con la política de privacidad. Google recomienda revisar logs cuando se sospecha actividad inusual y segmentar el tráfico por canales y unidades, pero se reserva los detalles del filtrado.

3. Ejemplo de análisis de logs agregados

El siguiente ejemplo asume que el proxy escribe una línea JSON por petición con campos time, ip, path y status. Agrupa las peticiones por minuto, ruta y una clave HMAC, y no imprime la IP original. El límite de 120 es un valor de demostración para que se vea el flujo; debe derivarse del patrón normal del sitio y no se interpreta como prueba de click bombing.

import hashlib
import hmac
import json
import os
from collections import Counter
from pathlib import Path

secret = os.environ["LOG_HASH_KEY"].encode("utf-8")
counts = Counter()

for line in Path("access.jsonl").open(encoding="utf-8"):
    event = json.loads(line)
    minute = event["time"][:16]  # ejemplo ISO: 2026-10-18T14:32
    ip_key = hmac.new(secret, event["ip"].encode(), hashlib.sha256).hexdigest()[:12]
    counts[(minute, ip_key, event["path"])] += 1

for (minute, ip_key, path), hits in sorted(counts.items()):
    if hits > 120:  # umbral ilustrativo; calibrar con línea de base
        print(minute, ip_key, path, hits)

La clave LOG_HASH_KEY debe guardarse fuera del código y ser estable durante el periodo de comparación, pero rotarse según el plan de retención. El script agrupa peticiones, no clics ni impresiones publicitarias. Una salida elevada se contrasta con user-agent, códigos HTTP, ruta y analítica agregada; nunca se bloquea a una persona automáticamente por una sola ventana.

4. Rate limiting y reglas WAF con alcance reducido

Aplica límites a rutas que el sitio controla y que suelen abusarse —por ejemplo, un formulario o endpoint de búsqueda—, no a cada visita HTML ni a las llamadas externas de AdSense. Un WAF puede aplicar desafíos ante patrones confirmados, bloquear una ruta automatizada o limitar peticiones por IP; registra falsos positivos y define una forma de recuperación. El bloqueo de un ASN completo puede cortar redes móviles, universidades, VPN empresariales o crawlers legítimos, por lo que requiere evidencias y un periodo de observación.

# Ejemplo para Nginx: limitar solo un endpoint propio de contacto.
# Declarar la zona dentro de http{}; ajustar la tasa a tráfico legítimo.
limit_req_zone $binary_remote_addr zone=contacto:10m rate=10r/m;

server {
  location = /contacto/enviar.php {
    limit_req zone=contacto burst=5 nodelay;
  }
}

La regla requiere un servidor Nginx o un proxy compatible; no se pega sin más en .htaccess ni en un panel que no lo use. Para Googlebot y el crawler de AdSense, no confíes en una excepción basada solo en el texto del user-agent. Verifica peticiones de Google por DNS inverso y rangos publicados; el user-agent puede ser falsificado. La guía de verificación de Googlebot explica este principio. No bloquees por defecto Googlebot o Mediapartners-Google; evalúa origen y función antes de desafiar una solicitud.

5. Cabeceras sin romper la entrega publicitaria

Las cabeceras deben limitar capacidades que el sitio no necesita sin inventar una allowlist obsoleta de dominios publicitarios. La guía actual de AdSense indica que, si se elige CSP, se debe seguir su recomendación de CSP estricta con nonce; los dominios que usa el código cambian y una lista rígida puede interrumpir la publicación. CSP no es un requisito de AdSense. Primero despliega la política en modo de solo informe, inspecciona violaciones y prueba la CMP, los bloques y la navegación.

Content-Security-Policy-Report-Only: object-src 'none'; base-uri 'none'; script-src 'nonce-{NONCE_ALEATORIO_POR_RESPUESTA}' 'unsafe-inline' 'unsafe-eval' 'strict-dynamic' https: http:; report-uri /csp-report
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: SAMEORIGIN

El valor entre llaves es un marcador de ejemplo, no una cadena que se deba publicar fija: el servidor debe generar un nonce aleatorio por respuesta y aplicarlo a cada script permitido. Un sitio estático sin generación en el servidor o en el edge no puede convertir un nonce fijo en una política estricta. En ese caso, no añadas una CSP copiada sin arquitectura que la respalde. X-Frame-Options: SAMEORIGIN es apropiado solo si no se necesita que un tercero enmarque la página; afecta al documento del editor, no al frame de anuncio hijo.

La auditoría del inventario debe incluir también quién declara venderlo: contrasta las líneas autorizadas con la guía de ads.txt, sellers.json y SupplyChain.

Errores frecuentes y respuesta

• Bloquear al primer pico: conserva ventana, rutas, códigos y origen; compara con releases, campañas y crawlers antes de activar una regla.
• Tratar un CTR alto como prueba: revisa impresiones y visitas, normaliza por formato y segmento, y consulta AdSense; no uses un umbral universal.
• Permitir un bot solo por su nombre: verifica IP/DNS y user-agent, pues el nombre puede falsificarse.
• Aplicar CSP de lista estática: comienza en Report-Only y usa la guía estricta actual de AdSense; nunca añadas unsafe-inline a ciegas.

Preguntas frecuentes

¿Los logs prueban quién hizo clic?

No. Habitualmente los logs del publisher registran páginas y recursos propios, no el click que ocurre dentro de un iframe de Google. Úsalos como contexto y no para identificar a una persona.

¿Debo bloquear una IP si la veo muchas veces?

Solo tras validar la ruta, el volumen, falsos positivos y necesidad. Google recuerda que una IP puede compartirse y no ofrece una lista de clicks válidos o inválidos por visitante.

¿Una CSP es obligatoria para monetizar?

No. Si decides usarla, prueba la cabecera en modo informe y aplica el nonce correctamente a cada respuesta y script permitido.

Complementa esta auditoría con la guía de integración del código y el análisis de políticas y cumplimiento. Fuentes: prevención de tráfico inválido, investigación de actividad inusual y CSP estricta para AdSense.