One of the great problems of teaching computer science is that there is a limited amount of time to teach and an unlimited amount of things that can be taught. There is very little degree of agreement of what must be taught. Teachers do the best they can but there is a good amount of variation on what gets taught. One thing that seems to always (or close to always) get left out is writing safe and secure code.
Few teacher give more than a cursory mention of error handling for example. The try/catch keywords get a little use but not much. For the most part, when a student program goes wrong it just crashes. Student programs tend to depend on the user entering information in the way the program is set up to receive it. This works, more or less, in the context of student projects because the projects are generally designed to test or use specific concepts other than error handling.
Outside of school, validating data as it is input is pretty important. There is a classic XKCD comic that highlights this idea. Bonus as it includes a school context. This is one way to at least talk about the concept even if there isn’t a lot of time and ability to reenforce it with a project. Though, string manipulation projects are sometimes a good way to talk about writing code to force specific forms of data formatting.
Back in the day, learning C (before C# or even C++) we talked a lot about memory management and things like overflowing strings and buffers. Ignoring those things was a major cause of security breaches. That’s probably true today as well. Modern languages with string objects, garbage collection, and other forms of memory management reduce some of the risk but students will benefit with some discussion of the topics.
Another topic that merits some discussion is validating where inputs come from. Data from a user input is obvious, usually. Data from files a bit less obvious. Data from other code is the least obvious and potentially the highest risk.
Many years ago I was part of an operating system development group and we were adding many layers of security. Great stuff but we thought a great deal about making sure the right security information was passed along. Code deep in the OS was responsible for sharing security information with user level code. We worked hard to make sure that only trusted information was allowed to reach different levels of code. We also worked hard to make sure that only reliable information went down to lower levels. That users can’t always be trusted is an important lesson at any level.
Secure code is a complicated issue of course. I have a great book called “Writing Secure Code” and it is almost 800 pages long. Not realistic for a high school CS class of course. I do think we can and should spend some time on the topic though. Ideally in the context of various other topics during a course. A few stories, or even cartoons, may help make the topic more memorable.