Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I want to know why calling a database from the front end is considered a bad practice for security.

It is really so bad as to justify building an application layer with all its drawbacks: costs, performance, development time?![enter image description here][1]

http://s21.postimg.org/oy72dp96f/lan.jpg

share|improve this question
1  
It is expected to do some basic research before you post a question here. Please read security.stackexchange.com/faq –  Shurmajee May 14 '13 at 13:39
    
With front-end, you're referring to some sort of a thin client in a multi-tier environment, is that correct? –  TildalWave May 14 '13 at 16:31

3 Answers 3

I'm not sure what exactly you mean. Separation in to layers like application and business logic and data access is not so much about security as it is about maintainability. It's done to make the code useable and be able to do things like change the database you use without having to fully rewrite the application.

It does also make security easier as you can secure the DAL to ensure that SQL calls can't be abused, but the same thing can still be done with a little more effort even if your code is completely flat.

So your initial premise that it is a bad security practice isn't exactly correct, it's just a bad programming practice in general. The fact that it makes security more difficult to implement well is just a secondary effect of the bad general design.

share|improve this answer
    
The front end code (JavaScript) is visible to the world.one just can't put the db access credentials in the front end code –  Shurmajee May 14 '13 at 13:42
    
no! front-end isn't javascript! frontend are the servers that host the ui of the application and sometime also the business logic and data logic –  Jon smith optional May 14 '13 at 13:46
3  
@MayankSharma - that's the client side. In my experience, front end generally refers to the logic that actually renders the HTML where as the back end is the "brains" of the site. The typical pattern is for a front end to request data from the back end via calls that can be swapped out to make it run off of any DB platform. So DB + DB layer is backend, HTML generation is front end and business logic can live in either, depending on approach. –  AJ Henderson May 14 '13 at 13:49
    
@AJHenderson thanks,that clarified my doubt –  Shurmajee May 14 '13 at 14:38

A database connection will let the user do pretty much anything he likes to the database, provided he has the access rights. Open a connection straight to the Internet, and the only thing keeping any user from admin account access is the secrecy of the password of the admin account. For the most part, you won't see a database system built with this sort of access in mind, so you won't see protections on the database itself that are crafted for this usage.

Given admin access, and connectivity, a hacker can:

  • delete the database entirely
  • rewrite the schema of the database
  • resize the database, consuming more machine resources than you intended
  • change the data in the database

So.. the return question is - what's the purpose of the database, and how much does it's integrity matter? If this is a test database for a student project, you may care more about the machine itself than the database. But in most applications, the information in the database and it's validity, availability and reliability are the heart of the system. Loose that, or loose your trust in it and in many cases, you no longer have a functioning business.

Speaking as a web developer, though - the biggest driver to having a web app is still not security - it's functionality. People don't tend to think in SQL - so you need an interface that lets a less technical user view and manipulate data in a way that the user can comprehend. Once you admit, even in one case, that you need a web server or app server to render the data into a user-readable page - then you've bitten off the need for the bigger costs of staging the application server. And once you've invested time and energy in developing forms or other data input mechanisms that the average user can use, you've invested enough in the site overall, that doing it correctly - with solid security practices is a wise investment not only to protect your data, but to protect the value of the investment in building the application.

share|improve this answer

I'm a little unclear on what you mean by "front end" but if you are talking about somehow firing database commands directly from the client side of a web application this would be very bad.

Any client side javascript you have can be easily modified or circumvented entirely, meaning that any command you execute from the client side could be modified to do whatever a malicious user wants. For example they could change your command from: SELECT * FROM Products to DELETE Products

In addition to that, it is a bad idea to have your database server accessible from the internet. Typically you want to have a web server that is accessible from the internet and then your database server would be available to the web server.

share|improve this answer
    

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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