sécurité blind injection sql

[julp]

Je rajouterais :

• $ip n'est jamais échappée (injection en ajoutant une entête HTTP ?)
  
• Pourquoi faire un SELECT pour UPDATE un compteur ensuite quand on peut le faire directement en un unique UPDATE, ce qui permettrait d'ailleurs d'assurer que la valeur n'a pas été modifiée entre le SELECT et l'UPDATE
  

Si le intval, avec la valeur 0 ou je ne sais quoi, est problématique, il y a toujours moyen de valider avant (filter_var, ctype_digit, etc).

Pour les script de redirection il est clair que ce n'est pas ce que je voulais utilisé, mais il se trouve que lors de la mise en ligne de mon site plus aucun ne fonctionnaient (je suis chez 1&1), donc j'ai du recourir à cette alternative, si tu connais une façon de faire fonctionner un header location je suis preneur.

Symptôme typique des gens qui :

• envoient du "contenu" avant les fonctions d'entête (setcookie, header et session_start)
  
• ont un environnement de développement où l'output_buffering est à on (cf phpinfo) donc ils ne se rendent même pas compte lors de leur dév qu'ils envoient des trucs au client (puisque PHP met tout en tampon - inutile de compter sur l'output_buffering non plus). Et c'est seulement quand ils passent "en prod" sur un autre serveur (où l'output_buffering est à off) qu'ils s'aperçoivent que ces fonctions ne marchent pas/plus
  

Et ce n'est pas un ob_start qui viendra à bout d'un BOM.