Many PL/SQL developers view security as an activity that only database administrators and security administrators need to be concerned about. It's certainly true that some aspects of security are the responsibility of DBAs—for example, performing user and privilege management and setting the password for the listener. However, it would be a gross mistake to believe that security is merely a DBA activity, one that does not belong on the plates of PL/SQL developers. For one thing, security is not an end unto itself; rather, it's an ongoing process and a means to an end. For another, a lot of administrators are more likely to spend their efforts securing the database as a whole rather than programming the security features of an individual application.
You've probably heard that "a chain is only as safe as its weakest link." This adage could have been written about application security. Every element of the entire infrastructure—application, architecture, middleware, database, operating system—contributes to the overall security of that infrastructure, and a failure of security in any single component compromises the security and increases the vulnerability of the entire system. Understanding the building blocks of security and incorporating them into your application design is not just desirable, it's essential.
Oracle security topics fall into three general categories:
Those that are exclusively in the DBA, system administrator, ...