¿Es seguro este esquema anti-falsificación?

Su enfoque parece ser una implementación válida de las medidas de CSRF: usar un token que se envía fuera del mecanismo de cookies.

Cosas a considerar con su enfoque:

• Asegúrese de que la clave aleatoria para cada usuario se genere utilizando un método criptográficamente seguro.
• Por entrada "peligrosa" supongo que te refieres a todas las solicitudes POST; si es así, ese es el enfoque correcto siempre y cuando no tengas solicitudes GET que alteren los datos (lo que generalmente no es un buen enfoque en sí mismo). li>
• Tendría una clave única basada en la sesión del usuario en lugar de una fecha en los últimos cinco minutos. Lo mejor sería utilizar un hash de la ID de sesión y la clave de usuario en lugar de incluir la fecha, lo que hará que las cosas sean un poco más seguras y menos propensas a que se descubra la clave de un usuario si un atacante tiene acceso a otra cuenta de usuario para un Período anterior a cualquier ataque.
• No intentaría hacer que un token CSRF proteja contra ataques de reproducción, este no es su trabajo. HTTPS lo protegerá contra esto .

También puedes ver el Hoja de referencia de prevención de falsificación de sitios (CSRF) .

CSRF es un problema resuelto. Consulte Hoja informativa de prevención de CSRF en owasp .