I feel that you could benefit from some general information on the subject of sanitization and escaping.
- To understand how to write secure PHP code, you need to prevent
against XSS.
- To prevent against XSS, you need to
implement proper output escaping and may need to implement data sanitization.
- To implement data sanitization and output escaping you need to understand why it's a problem and how to do it properly.
Sanitization
Sanitization should be done before saving the data to the database. It makes sure that things which shouldn't be saved to the database are not. It is also good to do it again after you read data out of your database incase you miss something and your database now contains something harmful. Generally if you are just storing text, you might want to allow any text to be saved and in this scenario sanitization is not really necessary. But it sounds like you are storing html...
If you are storing html you probably plan to output it to browsers at some point and you don't want it to contain harmful scripts for your users to execute. Sanitizing html to remove harmful javascript is actually very very difficult due to the many ways you can insert javascript. Whole PHP libraries (e.g. wp_kses_*) have been written dedicated to this and it's not enough to just remove all < script> tags as some SO answers suggest. Plus you will need to keep your html sanitization code up to date to prevent against the newest attacks. All in all, it's a very high risk/maintenance solution. If you want to go this route, there are some solutions here.
Usually you will want to give your users the ability to format their text with a subset of what html offers (e.g. bold, italics, underline and maybe some colours) and a better approach is to use a more lightweight language such as Markdown or BBCode
Also you should consider saving your fields as text only and handle the styling completely in your application.
Output Escaping
This is the step right before outputting the data. When you are piecing together HTML for output in PHP, you need to convert anything which isn't html yet in to safe html. If you use a templating language this is handled for you automatically. In my opinion it is the most misunderstood concept of PHP developers today, and unfortunately it is one of the most important. I won't go in to it here but I highly recommend this further reading.
Important Update
This code is NOT data sanitization, it is output escaping.
filter_var_array($row, FILTER_SANITIZE_SPECIAL_CHARS);
I can see now that confusingly, the word "Filter" has such a generic meaning in this answer and can arguably refer to both sanitization and escaping. I have removed it from my answer to help clear up any confusion.
Your example - Sanitization
I wont go as far to say never store html in a database field, but it is a lot harder this way. You need to decide what is expected and valid. If you update your question with more details on the specific data, it will become clear what these restrictions should be.
Your example - Output escaping
If your variables already contain well formed HTML fragment strings then you can safely append your variables using the "." (string concatenation operator) inside an open and close tag. What you have put in your question code is correct. However, I prefer to use direct output with short tags as it makes the code more readable and there is no real need to put everything in to a PHP string anyway.
<td><?= $row['tokens'] ?></td>
<td><?= $row['direction'] ?></td>
<td><?= $row['graph'] ?></td>
<td><?= $row['module'] ?></td>
Note: As explained above, by outputting html you are asking clients to trust, parse and display it. If these variables do in fact contain invalid or bad HTML, then it is a problem with your sanitization.
- Output escaping should/does NOT clean your data.
- Sanitization should/does NOT escape your data.
They are simply two different concepts working together.
Since your id should be an integer from your database you can cast it like this to make sure that it is.
<a href='upong.php?soya=<?= (int)$row['id'] ?>Specific type</a>
If the value is not castable to an integer (because something unexpected happened which you didn't account for) you end up with a 0 in your url which normally isn't that harmful.
