As soon as you forget (or your adversary manages to delete) an \0 at the end of any string, you may induce buffer overflows, get the application to leak secrets, and so on. Several standard library functions related to strings are prone to timing attacks, or have weird semantics that may expose you to attack. If you roll your own security-related functions (typical example: a scrubber for strings that hold secrets), you need to make sure these do not get optimised away by the compiler.

There's an awful lot of pitfalls and footguns in there.

▲

trashb an hour ago | parent [-]

I thought you meant a hello world or similar program only handling strings would be fundamentally insecure but rather you mean that it is hard to write secure code with C strings.

There are indeed a lot of pitfalls and footguns in C in general but I would argue that has more to do with c's memory focused design. I always feel like C strings are a bit of an afterthought but it does confirm well with the C design. Perhaps it is more so a syntax issue where the memory handling of strings is quite abstracted and not very clear to the programmer.

	▲	lou1306 an hour ago \| parent [-]
		> I thought you meant a hello world or similar program only handling strings would be fundamentally insecure but rather you mean that it is hard to write secure code with C strings. Disclaimer: I am not the author of the comment, and honestly I am more than happy if OpenBSD broke %n in printf because it looks awful from a security standpoint. > you mean that it is hard to write secure code with C strings. Indeed I do :) It is possible to write a "secure" hello world program in C; the point is that both the language and the standard library make it exceedingly easy to slip in attack vectors when you deal with strings in any serious capacity.