Category: best-practices

What is CSRF (Cross-Site Request Forgery)?

Cross-Site Request Forgery (CSRF) also known as session riding or one-click attack is a security attack that executes unwanted actions on a web application on behalf of a logged-in user.

To understand this, take this scenario: suppose there is a user logged-in to their account (perhaps on a social media application). To track user sessions, the application stores cookies in user's browsers. When a user gets authenticated, a cookie is saved on their browser and on subsequent calls that they make to the application, the cookie gets sent with the request.

The cookie contains identification data that lets the application know who the user is, the actions they can perform and what they have access to. The cookie gets reused until it expires, gets invalidated or is deleted by the user through their browser settings.

Now suppose, the logged-in user was surfing the internet and they happened to be on a website made to try to perform CSRF attacks on the social media website the user uses. This malicious website won't make this obvious of course, it will most likely be an innocent-seeming website that runs scripts on the background.

Let's say the website is a file-sharing one. It would carry out the attack by having on-click listeners on links that users are likely to click on. When the user clicks on the link, a request will be made to the social media application with the user's stored cookie. When the app gets the request, it will honour it since it contains a valid cookie. The attackers will thus be able to run commands on the user's behalf.

A Definitive Guide to Sensible Form Validations

Here is one of form validation error messages that made me laugh aloud : "invalid last name. Please enter a valid last name". The form (or the souls that coded that form) decided my last name is bad and imagine, they want me to build a valid last name too!

How to validate an email address using JavaScript

Validating email address using regular expressions is tricky and is often not recommended. The reason is simple. A valid email address as defined by RFC 2822 can be quite complex.

A valid email is of the format: name@domain

The name can be a set of 'atoms' separated by dots. In its simplest form like this: john.doe@domain

now, the atoms can contain

  1. alpha-numeric characters
  2. Any of these characters ! $ & * - = \^ ` | ~ # % ‘ + / ? _ { }
  3. single or double quotes and any character inside the quotes

Now, to the domain part. Most email validation checks assumes that the top level domain can have up to 4 characters. It is not true. There are TLDs like this: .MUSEUM .travel, .international or even .vermögensberatung

For example all the following email addresses are valid:

  • あいうえお@a.long.domain.example.university
  • one.“more\ long”@example.website.place
  • customer/department@example.com

Writing a email validation that validates for all those cases is difficult but possible. Here is an email suggested from this post: