Witam.

Pobierając dane poprzez mysql_fetch_assoc zapytaniem:

mysql_query('SELECT * FROM tabela where id = "5"') or die(mysql_error);

Pole id 5 jest pobierane poprzez $_GET

Jeśli go nie przefiltruje to jest jakieś niebezpieczeństwo takie, że po wpisaniu jakiś poleceń zamiast "5" może zapytanie przerobić się w update albo delete ?
Jak to wygląda ?

Wpisze sobie w Google to znajdzie setki przykładów jak to wygląda...
Nie trzeba każdemu tłumaczyć od nowa..

Poza tym Twoja wypowiedź jest daleka od prawdy.

[PHP] pobierz, plaintext 
mysql_query('SELECT * FROM tabela where id = '. (int)$_GET['id']);
[PHP] pobierz, plaintext 

Nie filtrowałem GET - shakuj mnie.

Wystarczy jakiś błąd w PHP (a w przeszłości już różne kwiatki działy się z liczbami) i leżysz.

Najpierw sprawdź czy przesłany identyfikator spełnia założenia ( np.: przez wyrażenia regularne, a w przypadku wartości liczbowej np.: przez funckję

[PHP] pobierz, plaintext 
is_numeric
[PHP] pobierz, plaintext 

), następnie sprawdź czy w bazie danych występuje rekord dla podanego identyfikatora ( np.: przez SELECT count(*) ), gdy wartość będzie spełniała kryteria dopiero pobierz dane z bazy. Dodatkowo, możesz zweryfikować czy użytkownik uruchamiający zapytanie ma odpowiednie uprawnienia w bazie danych ( o ile wogóle w niej wystepuje ).

wizarts niepotrzebne kroki. Po co walidacja is_numeric?
PDO bądź coś zbliżonego co zabezpiecza nas przed takimi problemami.
I tyle. Haker zmienia ID na string, wykonuje się zapytanie, nie znajduje artykułu, nic się nie dzieje.
Wyświetlasz "Nie ma artykułu" i to wystarczy w zupełności.
Po co wyświetlać "Wpisane ID nie jest numeryczne", "Podany string nie spełnia założeń wyrażenia regularnego"?

Potem po co dwa zapytania do pobrania artykułu? Pobierasz jeden wiersz po indeksie ID czyli bardzo lekkie zapytanie.
Pobierasz, sprawdzasz czy pobrało wiersz i jeśli masz tablicę/obiekt to już nie musisz wykonywać kolejnego zapytania.

Miałem na myśli jedną metodę walidacji, czyli gdy spodziewam się, że identyfikator ma być liczbą sprawdzam go funkcją is_numeric bądź wyrażeniem regularnym, a w przypadku, gdy identyfikator jest stringiem sprawdzam przy pomocy regular expressions.

Powyższe sprawdzenie wykonuje bez informowania użytkownika o tym czy wartość przeszła walidację czy nie wyświetlając jedynie ostateczny komunikat, że nie znaleziono artykułu.
Dwa zapytania właśnie poto, żeby w przypadku wartości nieliczbowej uniemożliwić sql_injection.
SELECT count(*) nieznacznie obciąża bazę, więc aplikacja ponosi niewielki koszt wydajności w porównaniu do zwiększenia bezpieczeństwa.

Nigdzie nie widziałem w poważnej aplikacji aby przy każdym pobieraniu danych z POST/GET ktoś używał is_numeric.
Jakby to był sposób na bezpieczeństwo to ta funkcja pojawiała się kilkaset razy w średnim projekcie - oczopląsu by można dostać.

Is_numeric służy do walidacji formularza - do zweryfikowania czy użytkownik wpisał liczbę w pole "wiek" oraz do innych, mniejszych spraw, nie do poprawy bezpieczeństwa.

I tak samo wyrażenia regularne - jak wyżej, tutaj już mają wpływ na bezpieczeństwo ale bardziej w wyszukiwaniu niebezpiecznych znaków, stringów itp.

W jaki sposób zapytanie COUNT zwiększa bezpieczeństwo skoro tu oraz w zapytaniu SELECT dodajesz ten sam warunek WHERE z tym samym stringiem pochodzącym z zewnątrz?
Bzdura.

Fakt. Nie do końca to przemyślałem.