Is it better to store user data in a database rather than in cookies? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

Improve this question

Why don’t we save the cookie information of website visitors (subscribers) in the database rather than setting a file on the user's machine. Yeah, I know I might sound silly for the following reasons:

1. Maintaining database information for every single user for ever small ‘chunk’ of data is difficult.

2. It might be difficult to retrieve data when the database server is down.

3. Continuous requests are to be made to the web server for each and every small piece of information.

My point is, If we are going to store the user’s data in a database rather than in a file on the client’s machine, we can provide security to the client by not allowing other organizations or other sites (or even hackers) to access the user’s information from the cookies.

Moreover, we can track the user's activities or behaviour. (I mean, we actually don't know what the user is doing (client-side activity) like data-tampering.)

If you feel that it might be difficult to send requests to web server continuously, it isn’t, thanks to Ajax. This gives some support to my position: sending requests to a web server made so simple using Ajax.

So, is it a good idea to store the user’s sensitive information in a database rather than setting a small file on the user’s machine?

To be specific, I’m not talking about sessions!

Answer 1

Your approach is definitely valid but has one fundamental problem (which is probably the reason for why cookies were created in the first place): identification.

How can you identify user A vs. user B without asking for a username/password? Cookies provide an easy way to make this differentiation. Once the user is identified, your points become completely valid.

Generally, sensitive information is not meant to be stored in cookies. Such information is best stored on the server side (as you indicated).

Answer 2

Sensitive information shouldn't be in a cookie, I'll agree with you there. It should be stored somewhere server-side, either in a flat file on the server itself, or in a database.

What you do need on the client machine is one small cookie containing some obscure, hard-to-guess reference to this sensitive data.

Congratulations! You've just reinvented sessions!

(Webservers can be set up to store session data in a database instead of in flat files on the server if you prefer it that way.)

Answer 3

It's true that the conventional wisdom is to avoid using cookies for sensitive data because they are stored on the client and a hacker can tinker with them and possibly do damage. However, there's a compelling reason why cookies might be worth a second look: Scalability. It's difficult to have a high-performing pool of session data available to an arbitrary number of cloud servers:

http://aws.typepad.com/aws/2012/04/scalable-session-handling-in-php-using-amazon-dynamodb.html

Here's a link I found which goes into great detail about how a secure cookie system might be built:

http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf

So it might be that what's old is new again.

Answer 4

Generally we use cookies because we're not necessarily setting any sensitive data in them. If your application does has sensitive data that you don't want anybody fiddling with then by all means use every server-side and DB tool at your disposal to solve that, but not all applications and implementations need that level of security in these respects. Setting cookies is for convenience, that's all.

Answer 5

This is done already, or we'd be storing user names, addresses, and credit card information in a cookie rather than on the database. You have to evaluate what makes sense to keep in the database vs. what makes sense to store as a cookie. Server performance, bandwidth, scalability - all of these have to be kept in mind. Remember that the more we store server side, the more we'll have to deliver client-side.

You also mention sessions - sessions are cookies (kinda).

Answer 6

I came across this post whilst looking for some similar advice related to the cookie vs database argument.

Say, I have some user data in the form of integer lists, i.e. some bookmarked products, a max of 80 per user.

In the database, this could transpose to say 4 tables (1 for each data type), so that's 20 rows per user.

If you had a million unique visitors per annum and for arguments sake 70% were guest users as opposed to members, then this could add 14m rows to a table, which otherwise might be just 6m rows. Of course you could have a cull policy for guest users, but that becomes awkward to manage accurately - whats to say a user doesn't return after 9 months to find his/her data wiped.

The other side of the coin is that guest data is stored in cookies, so it doesn't matter how long its stored. I appreciate that more work is involved managing two storage methods but thats the only downside I can think of.

Anyone got any views on this, as I'd appreciate some advice.