Writing secure shell scripts?! How can shell scripts be secure when you can read the source code?
Any system that depends on concealing implementation details is attempting to use security by obscurity, and that is no security at all. Just ask the major software manufacturers whose source code is a closely guarded trade secret, yet whose products are incessantly vulnerable to exploits written by people who have never seen that source code. Contrast that with the code from OpenSSH and OpenBSD, which is totally open, yet very secure.
Security by obscurity will never work for long, though some forms of it can be a useful additional layer of security. For example, having daemons assigned to listen on nonstandard port numbers will keep a lot of the so-called script-kiddies away. But security by obscurity must never be the only layer of security because sooner or later, someone is going to discover whatever you’ve hidden.
As Bruce Schneier says, security is a process. It’s not a product, object, or technique, and it is never finished. As technology, networks, attacks and defenses evolve, so must your security process. So what does it mean to write secure shell scripts?
Secure shell scripts will reliably do what they are supposed to do,
and only what they are supposed to do. They won’t lend themselves to being
exploited to gain root access, they won’t accidentally
rm -rf /, and they won’t leak information, such as passwords. They will be robust, but ...