Tach!
Und nicht vergessen: Alles was über HTTP kommt ist der DB entsprechend zu maskieren.
Diese Aussage ist nur teilweise richtig. Es kommt nicht darauf an, wo Daten herkommen. Sie müssen in jedem Fall kontextgerecht behandelt werden, wenn sie direkt irgendwo eingefügt werden, beispielsweise wie hier in ein SQL-Statement. Das Ziel muss nicht nur im Falle von über HTTP kommenden Daten syntaktisch einwandfrei und der Intention des Autors entsprechen, sondern generell. Außerdem gibt es mit Prepared Statements eine Alternative zum Maskieren.
Im Ausgangsposting ist unter anderem zu sehen:
WHERE (Fototag1>=$Datum)
Wenn nun in $Datum ein Wert à la 2019-02-18
steht (ohne Anführungszeichen), dann ist das kein Datum sondern eine Rechenaufgabe mit dem Ergebnis 1999, was im Vergleich mit dem in Fototag1 stehenden Datum nicht den gewünschten Sinn ergibt.
... WHERE (Fototag1>='" . htmlspecialchars($Datum) . "') ...
So wäre zumindest dieser Teil syntaktisch richtig (mit einfachen Anführungszeichen um das Datum und Maskierung des Wertes). Wenn nun jemand kein Datum, sondern irgendwas anderes eingibt, kommt zwar kein sinnvolles Ergebnis raus, aber man kann diese Stelle auch nicht mehr für SQL-Injection ausnutzen.
Zudem ist es nicht weiter sinnvoll, für das Datum eine weitere Variable anzulegen.
$Datum = $_POST['datum'];
Man kann den Wert im $_POST-Array, was auch nichts anderes als eine Variable ist, auch gleich direkt verwenden
... WHERE (Fototag1>='" . htmlspecialchars($_POST['datum']) . "') ...
dedlfix.