0

im trying to create a simple website with HTML/CSS and Javascript. Basically the user should be able to input a number into a textfield and "send it" with a button. When the button got pressed i want to run a Javascript function that searches the number in a sql database. Creating all that stuff shouldnt be a big problem for me, but i have no clue how to create a safe connection between JS and SQL. I have read that a direct connection with javascript is very insecure.

Some people recommend to use java or c# to built an sql connection. How would that work? Basically just an Javascript code, that runs an java/c# application(which builds an sql connection) and returns the needed sql data? Also heard that its possible to create a sql connection with node.js, is this safe? Or is another method more suitable?

Greetings

Kageyasha
  • 31
  • 4
  • 7
    You need server-side code, in any server-side language (including Node.js). – SLaks Mar 12 '18 at 14:21
  • 1
    Using JavaScript to connect to SQL is not insecure. But using code that runs on the client side (which could be JavaScript) to directly connect to a service where you need login data that should not be known by anyone is insecure, because you cannot hide such login data on the client side. – t.niese Mar 12 '18 at 14:24
  • 1
    You should not blindly build SQL string from user inputs, regardless of the back-end system. – Diodeus - James MacFarlane Mar 12 '18 at 14:24
  • 1
    Agree with @SLaks, you'll need some sort of server-side application. You should never expose a database directly. – phuzi Mar 12 '18 at 14:24
  • The only thing you can do is to use server-side approach (webservices, microsevices, Etc), period! Any answer rather than this is waste of time. – Ele Mar 12 '18 at 14:31

3 Answers3

1

I have read that a direct connection with javascript is very insecure

The danger is in giving direct access to your database to the client. JavaScript is most commonly run client-side in web browsers, so for it to access the database you would have to give the browser (and thus the visitor) a username and password on your database server and let them run raw SQL.

There are many possible security risks with this and it just isn't worth it.

(Aside: You can't make arbitrary socket connections with browser-side JavaScript, so it's impossible to connect to most database servers from it anyway).

If you want to expose data to JavaScript running in the web browser, then the standard approach is to write a webservice.

You can write the webservice in any programming language you like (including JavaScript). It listens for HTTP requests, reads data out of them, possibly performs authn/authz, the queries the database (applying the well-documented defences against SQL Injection attacks) and returns the result (often formatted as JSON).

The client-side JavaScript, therefore, just has to make an HTTP request (e.g. with XMLHttpRequest or fetch) with parameters passed in the query string or request body, and process the data it gets back from it.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
0

Connecting to a database using client side javascript is very insecure as the javascript will need to know the login details. And since the client side javascript is on the client side, any user will be able to see the login details in plain text.

The best way to do this is to make a webservice on a server. When the button is clicked it will make a GET/POST request to the webservice with the entered number as a parameter. The webservice, which can be made using any language pretty much, will create the connection with the database and insert the row itself.

Tom Dee
  • 2,516
  • 4
  • 17
  • 25
  • JavaScript can run on the server (nodejs), and is not a languages that is used exclusively on the client. – t.niese Mar 12 '18 at 14:26
  • Nitpick: if your Javascript is node.js running on the server, that's not insecure. The problem is direct unfettered access from a user-controlled environment (browser) to the database. – deceze Mar 12 '18 at 14:26
0

Although I would advise going the webservice route since it will be much easier to make secure. Playing with javascript to database is extremely dangerous unless you have a really good system and understand exactly what you are doing; but if you really want to do it and have an application that requires it, then can use PouchDB connected with CouchDB.

PouchDB is run locally and can sync with CouchDB over HTTP.

https://pouchdb.com/ https://couchdb.apache.org/

There is an answer here discussing basic security with pouchDb synchronizing with couchDb. Basically, each person needs separate login credentials and credentials should never be stored in the page code. PouchDB security

There are some neat uses for pouchDB: https://pouchdb.com/users.html

Halcyon
  • 1,376
  • 1
  • 15
  • 22
  • I've upvoted, this is correctly answering the question in a some what innovative way. While advising to still stick with the traditional way. – Tom Dee Mar 12 '18 at 14:40
  • @Halcyon Just curious. "unless you have a really good system and understand exactly what you are doing" How would you see that happening? I think if the javascript, (or any other code) runs clientside, it is never safe for database connections. Maybe on a private network where only people have access that are allowed to access the databse. But then it would still be a bad design i think – Mark Baijens Mar 12 '18 at 15:30
  • How I envisioned that working would be that they would need to enter their own credentials on the client side, so you have separate users (either created manually by CS or separated somehow in a different process or service) for anyone who needs to access it. You could store those in local storage if you really needed to for convenience in coming back-- but having any sort of credentials loaded over the wire in the page would be disaster for a public facing site, totally agree. – Halcyon Mar 12 '18 at 15:38
  • I probably wouldn't do it anyways though, even if it is possible, because it would be way too easy for a developer to accidentally slip and do something horrific (either the original guy or the next guy who maintains it...) it is much better to just separate it out. I'm having a hard time thinking of any application that wouldn't benefit from just having a backend, although the PouchDB list does have things like medical users who need offline access. – Halcyon Mar 12 '18 at 15:41