SQL injection generally occurs because parameters are capable of holding a lot of data. So if you have a character-based parameter that is longer than say 15 to 20 characters, and an application which allows free-form typing into that data field, and the query simply appends that string to the rest of the query without any validation, that's a hole a mile-wide that needs to get fixed. Nothing bad about having the RO schema, and certainly a good idea, but validating parameters is the most valuable thing you can do, and best to do so within the application.
Some of my parameters are fairly large, and difficult to sanitize, since they search for data that is not particularly well structured. And after years of working on this, I'm still a little vague on the interaction between roles, logins, users, schemas, inherited permissions and all of that. I've studied endless blog posts, forum posts, e-books, experimented with all sorts of things, but I still feel like I'm missing a solid overall grasp of the subject. Fortunately, this is a fairly low-threat environment, with no data that is valuable to anyone on the outside, and I'm religious about backups, so I'm not too worried, but I'd like to understand it all better.
One of the ways to sanitize long parameters involves some SQL keyword checking, and looking for obvious problems like the mere presence of the words TRUNCATE or DELETE or ROLLBACK or COMMIT or GRANT or ALTER. You can even go further and use a good string splitter and then count keyword matches with a table of SQL keywords. Jeff Moden's DelimitedSplit8K is particularly well performing for such a task, although going through that much effort for every record could still be problematic if the volume of things gets high enough.