Web development

Cookie: a small amount of information sent by a server to a browser, and then sent back by the browser on future page requests.
If your server has previously sent any cookies to the browser, the browser will send them back on subsequent requests.
Alternate model: client-side JavaScript code can set/get cookies.
  • Cookies are only data, not program code.
  • Cookies cannot erase or read information from the user’s computer.
  • Cookies are usually anonymous (do not contain personal information).
  • Cookies CAN be used to track your viewing habits on a particular site.

Security issues:

XSS attacks, SQL injection, bitmap injection, CSRF

Man-in-the-middle attack (network sniffing)

Session hijacking

Form validation scenario:

  1. A form is displayed.
  2. You fill it in and submit it.
  3. If you submitted something invalid, or perhaps missed a required item, the form is redisplayed containing your data along with an error message describing the problem.
  4. This process continues until you have submitted a valid form.

On the receiving end, the script must:

  1. Check for required data.
  2. Verify that the data is of the correct type, and meets the correct criteria. For example, if a username is submitted it must be validated to contain only permitted characters. It must be of a minimum length, and not exceed a maximum length. The username can’t be someone else’s existing username, or perhaps even a reserved word. Etc.
  3. Sanitize the data for security.
  4. Pre-format the data if needed (Does the data need to be trimmed? HTML encoded? Etc.)
  5. Prep the data for insertion in the database.

In order to implement form validation you’ll need three things:

  1. A View file containing a form and displaying error message in correct place.
  2. A View file containing a “success” message to be displayed upon successful submission.
  3. A controller method to receive and process the submitted data.


Encoding, and encryption too, are two-way processes. Passwords are secrets that must only be known to their owner, and thus must work only in one direction. Hashing does that – there’s no un-hashing or de-hashing, but there is decoding and decryption.

DO NOT use weak or broken hashing algorithms like MD5 or SHA1. These algorithms are old, proven to be flawed, and not designed for password hashing in the first place. Only use strong password hashing algorithms like BCrypt (which has a limit of 72 characters), which is used in PHP’s own Password Hashing functions.