##Hiểu về Rails Authenticity Token.
Vấn đề:
Khi người dùng xem một form để tạo, cập nhật hoặc xóa một resource, Rails sẽ tạo ngẫu nhiên một authenticity_token và lưu token này trong session, và đặt nó trong một hidden filed trong form. Khi người dùng submit form, Rails sẽ tìm kiếm authenticity_token, so sánh nó với một cái đã được lưu ở trong session. Nếu chúng phù hợp thì cho phép tiếp tục.
Tại sao lại có điều này:
Khi authenticity token được lưu ở trên session, phía client có thể không biết giá trị của token đó. Điều này ngăn chặn người dùng submit một form tới ứng dụng Rails mà không thông qua form của ứng dụng. Hãy tưởng tượng rằng bạn sử dụng một Services A, bạn đăng nhập vào Service đó, mọi thứ đều thành công. Bây giờ hãy tưởng tượng rằng bạn đã sử dụng Service B và bạn đã xem một bức anh mà bạn thích, và nhấn vào bức ảnh đó để xem với kích cỡ lớn hơn. Bây giờ, nếu có một vài mã ở trong Service B, nó có thể sẽ gửi tới Service A ( với Service mà bạn vừa đăng nhập), và hỏi để xóa account của bạn bằng cách gửi một request tới html http://serviceA.com/close_account điều này được hiểu như là CSRF(Cross Site Request Forgery).
Nếu Service A có sử dụng authenticity tokens, hướng tấn công này sẽ không còn được áp dụng. Từ đó những request từ Service B sẽ không thể có một authenticity token đúng và ngăn chặn việc tấn công đó.
Chú ý: Nhớ rằng Rails chỉ check authenticity token đối với POST, PUT, và DELETE request. GET request sẽ không được check authenticity token. Tại sao có điều đó? Bởi vì đặc điểm của HTTP là GET request không tạo, chỉnh sửa, hoặc xóa resources của server và request nên là idempotent (nếu bạn chạy cùng một câu lệnh nhiều lần bạn có thể lấy cùng một kết quả trả về cho mỗi lần).
Bài tập:
Sử dụng authenticity_token để bảo vệ request POST, PUT và DELETE. Đồng thời chắc chắn rằng khi tạo bao nhiêu GET request thì cũng không làm thể chỉnh sửa resource phía server
http://eren.0fees.net/2012/05/22/understand-rails-authenticity-token/