Web Development – Clearing Up Misconceptions About Flask Backend and Client-Side Rendering

The main point of a CSRF token is that it can't have been sent from another site. So therefore it (a) can't be predicted or detected by an attacker, and (b) is not automatically attached to a request the way a cookie is.

So theoretically if a CSRF token is never disclosed to third parties, again theoretically, you don't have to expire them at all. But then you run the risk of your token getting "leaked" somehow. So your expiry period really should be short enough to combat the prospect of a token getting out and being used against your user.

There aren't really any guidelines, but a good solid techique is to auto-generate a new token on EVERY request which embeds a signed timecode, and then accept tokens up to a certain age.

A sample function might be:

concat(current_time,salt,sha256_sum(concat(salt,userid,current_time,secret_string)))

The token contains timing information and a salt, but also contains a signature which can't be forged and which is tied to the userid.

Then you can define your own expiry interval -- an hour, a day, 2 hours. Whatever. The interval in this case isn't tied to the token, so you're free to set expiry rules however you want to.

At the very least, though, CSRF tokens should expire when the login session expires or when the user logs out. There's no expectation by the user that a form that you brought up BEFORE you logged out will continue to work AFTER you log back in again.

RobertHarvey is totally right: it depends. It could be a good solution but it is a terrible solution also for some projects.

In you question you state:

He has created a small website (there are apparently no dynamic contents)

Based on that he chose the wrong solution. Now you also note that there are animations. So maybe, if those are exceptional, it might be a good solution. Let's state those animation could also be made with normal solutions.

Whether it is good or right is then simple: If it should work like a normal website, so with a good ranking in search engines, good accessibility and all other standard webdevelopers take care of it is just wrong. You build a website with a goal. If that is: Have normal people visit it to subscribe/buy/view etc. it won't meet that goal.

His arguments:

Websites with a high amount of users do this to prevent server overloading.

Yes, but this is a small website right? http://c2.com/cgi/wiki?PrematureOptimization

It is easier to create new sections.

Likely he is unaware of other solutions. No problem, it's his first one. This is something where training / reading could do a lot.

It is easier to translate, as translations, texts and almost everything is loaded from a JSON.

Same here, localisation is something much more complex than just translating some pieces of text anyway. Education is here also the key.

You can expand more sections directly from a JSON file.

Might be correct, seems simple to do. If a user has to do it then it directly becomes more difficult. With a database for example it might be possible to create a form for that.

Everything is smooth, as you don't move to another page.

This is true but not undoable with other solutions. Loading pieces of content with ajax (with changing the browser history) might solve this well. https://developer.mozilla.org/en/docs/DOM/Manipulating_the_browser_history

To take this into a broader level: It is nonsense to build a dedicated framework if it is just a simple site. Use the basics or an existing system for it. On the other side, it's a nice learning experience. We all tried to build a CMS once right? ;) His arguments are not strong, if he want to work more in this area more knowledge would be advisable.