I am working on my first web development project, SQLite4Web. Long story short: SQLite4Web is a web interface for SQLite database files. The user can access their database via /db/{dbToken}, where dbToken is the database's unique identifier. In all cases, the HTML file sent to the user is the same (index.html). The html file, however, includes a script checking if there is a token in its HREF (as a query parameter or as a path). If it finds a dbToken, it makes a call to the API to receive the database's info (as JSON) and displays it. If the script, however, does not find any dbToken, it shows the normal homepage.

So basically, all website front-ent management is done in one single HTML file, client-side. Is this bad practice? (How) can I improve this system?

Thanks in advance for your help!

closed as too broad by BobDalgleish, Thomas Owens Mar 17 at 17:25

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


The fact that you have everything happening in the UI in a single HTML file I don’t think is a very big deal. What is a much larger problem is that the system you describe sounds extremely insecure.

If all I need to do is provide a {dbToken} in a URL parameter to access a database, then it’s really easy to access other people’s databases too as long as I can guess or find out their token. URL parameters can be cached by another system or intercepted and replayed by an attacker who is in the middle of your client and your server, or your customer and your client. Tokens can be guessed and brute forced if they have a predictable pattern (which, as a resource identifier, they often do) and do not have an expiry (which, as a resource identifier, they never do).

You need some additional form of authorization. You ideally need to know who your user is (authentication) and whether that user is permitted to access any given resource (authorization). Your application should receive information about this through some way that is not trivially intercepted (e.g. a POST if you use HTTPS).

There are many possible solutions for doing this. It is beyond the scope of a single Stack Exchange answer to list them all.

Not the answer you're looking for? Browse other questions tagged or ask your own question.