Til

TIL why potentially destructive actions on a user-facing API should NOT use HTTP GET

1 minute read Published:

Imagine a commentbox, where each comment has to be approved by the moderator in his backend. If the backend used GET requests for the comment moderation, the url to moderate a post should look something like this: http://yourdomain.com/moderate/:decision/:postid For example: http://yourdomain.com/moderate/allow/1 http://yourdomain.com/moderate/deny/2 … If some evil person posted a comment and knew their postid (lets say 12) they could try to email you a link to http://yourdomain.com/moderate/allow/12 with a caption that says Cute cat gifs, you would click on it and BOOM the comment would be published…


TIL when to sanitize user input in a web application

1 minute read Published:

When a webapp takes user input (like a blog post or comment) and later renders that input into a HTML-Page, the webapp has to ensure that no malicious <script> tags or anything else is delivered to the viewer. How to do that is actually pretty easy… Just replace " ' < and > with their HTML-Entity-Counterparts. But when do we have to do it?? Because we want the input’s author to see the exact same thing she entered into the text field, the webapp should not sanitize the text before it gets saved into the database, but rather before it gets delivered to the viewing client.