It seems like you've not covered your bases.
For the sake of example, let's say your application has two features: logging in and blogging. You'd expect your setup to be something like:
| | | |
| Login | | Blogging |
| | | |
| Database |
This is dramatically oversimplified of course but sufficient for the current answer.
I have prepared statements to prevent any harmful code from altering my database at the signup process
Your question implies that you've put the safeguard in your login logic. But as you've discovered, that doesn't cover all cases, as the blogging feature is still left unguarded.
I am capable of preparing statements for everything involving my database
It would've been much better to implement this safeguarding logic in the database logic. That way, any part of your application that uses the database will be forced to have its data cleaned up before anything hits the DB.
I want to know if I should be concerned about usernames writing sql code after they become strings in the prepared statements
I'm not quite sure what the proposed concern is. Reading your question at face value, it seems like you misunderstand what SQL injection is, since all SQL queries are strings, which means that you can't protect from SQL injection by using strings.
Secondly, the proposed solution of putting the logic in the database logic prevents this issue in all cases all at once. For example, let's say your user enters this as their username:
Robert'); DROP TABLE Students; --
This is a really well known form of SQL injection.
There are many ways to protect against SQL injection (parametrized queries are the way to go), but let's say that for the sake of example, you decide to write a simple cleanup script that removes all non-alphanumeric characters. This means that the actual username you'll be sending to the database will be:
Robert DROP TABLE Students
Which no longer works as a SQL injection attack because it no longer injects anything. The username will still contain some of the words, but as it's become harmless, it's not a problem for you.
Note: don't just roll your own cleanup script, because you might not know about every possible attack vector. Rely on existing cleanup methods so you know you've got a robust way of defending against attacks. I showed you a basic example to showcase the intent of a sanitization, not because you should totally do it yourself.
Note: Guran is correct that SQL injection is not the only thing you should take into account. Malicious users can inject JS which only activates when loaded into another user's browser. I suspect that most JS attacks will already break when being run through a SQL injection sanitizer (because JS and SQL share many syntax characters), but definitely look into that if JS attacks are also something you wish to protect yourself against.
however if the user goes to create a post, comment, or reply, my website will use their info like their username to create/display new data in the website
Any well built relational database (which SQL is the main use case for) is not going to enter the username a second time when that user saves a blog/comment/reply. All you're going to add is a blog/comment/reply entry with a user ID reference, which points to your existing user which you stored during the account creation process.
It's not impossible to use the username as the FK constraint, but it is somewhat impractical. It's much more commonplace to use the PK of the user table, which is usually an int or guid.
As per this SO answer, using a narrow primary key (like an int) has performance and storage benefits over using a wider (and variable length) value like varchar.
As to the possibility of SQL injection attack coming from the content of the blog/comment/reply itself, refer back to my proposed solution of ensuring you sanitize your database input on the database layer, as this automatically ensures that all entered data will be cleaned, and it doesn't require extra implementation work when you start adding features to your application.