Security and Performance

In Chapter 8 , you added two vital pieces to Claudia ’ s web site: a simple page manager and a

simple newsletter manager. In this chapter, you ’ re going to tie up two loose ends: security and

performance. You ’ re going to do an audit of security issues, and in the process tighten up some

issues on the administrative panels. In Chapter 3 , you opted to protect against XSS (cross - site

scripting) attacks, but that still doesn ’ t cover everything. For example, you haven ’ t addressed

form validation. You ’ re also going to do some basic performance benchmarking and then put

caching in place.

Please note that in a real project, you ’ d probably undergo security and performance issues in a

more immediate way, and, in fact, you have implemented various minimal safeguards as you ’ ve

progressed. However, because this is a book, and because security is such an important topic, it ’ s

likely that readers might skip to this chapter, and thus the topic is presented here as a whole.

Security

Web - based security is a pretty broad field, but at the end of the day, as far as you ’ re concerned,

security is a question of threat level (or vulnerability) and opportunity. In all likelihood, an attack

that is fairly common against a completely unprotected target will be tried long before an obscure

attack on an unknown or hidden target. Your job is not to defend against every possible situation,

but it is your job to make sure that your systems are secure enough to make the attacker try

somewhere else. What this comes down to is a “ defense - in - depth ” attitude that will help you keep

your applications secure from malicious users.

That being said, the number one rule of web application security is that user input cannot be

trusted. In fact, any data that are received from any process can ’ t be trusted. They should all be

considered tainted and need to be filtered one way or another. For example, 99 percent of the time,

the URI strings that are passed around will be OK, but someone will try to hack the URIs, trying to

pass in a very long ID, for example, to your model. Your job is to make sure that doesn ’ t happen.