<input type="email"
name="email address"
placeholder="Email address"
aria-label="Email address"
data-msg="Please enter a valid email address."

regarding above quoted input field (each param in a new line for easier reading purposes)

Are those kind of input fields, which check specifically for [email protected] SQL-Injection vulnerable in any kind of way? Do I risk being exploited by implementing this kind of input field (which I discovered being used by someone else, so no credits go to me for creating this code.)?

I mean by trying to exploit with "HARMFUL CODE"@test.com won't work, the harmful code itself won't work as well, etc.


<form class="js-validate mt-5" name="signin" action="/signin" method="post">

mentioned input field is member of said form class, which validates the SignIn via post-method, thus I think it's fairly secure implementing such code on a website, right?

1 Answer 1


SQL injection is a server-side vulnerability. It has almost nothing to do with your client-side code. If you do all your validation on the front end, what happens when a malicious user decides to not use your front-end at all, but instead send requests directly to the server?

So, this does not protect against SQL injection at all. To properly protect against SQL injection, implement server-side protections. You can use a modern web framework and/or ORM that completely abstracts SQL away, or follow the OWASP Cheatsheet.

  • Sure so you're the opinion that via intercepting the Post request and replicating it with a tool like sqlmap this site is still exploitable?
    – J. Doe
    Commented Apr 16, 2020 at 21:48
  • In fact, I just tested it - and it doesn't work. :)
    – J. Doe
    Commented Apr 16, 2020 at 22:07
  • 1
    Why intercept the request when I can simply do document.getElementById('signinEmail').type='text'; to disable local validation? I could send the parameters directly through curl, but that would be more annoying.
    – Ángel
    Commented Apr 16, 2020 at 22:10
  • 1
    No, I can execute that directly from the browser console. As you were so nice to include an id I took care of it. The way it is done is not relevant, though. I could use getElementByXPath, the browser inspector or edit a local copy of your page. You need to validate it server side. The will client side is controlled by the untrusted user (potential attacker).
    – Ángel
    Commented Apr 16, 2020 at 22:47
  • 2
    @J.Doe I'm a pentester, and I can 100% guarantee you that client-side-only validation does absolutely nothing to stop an attacker. You can either trust 3 security experts who all tell you the same thing and have credible sources to back up, or you can trust your own inability to perform a successful injection and use that as argument that you must be secure.
    – user163495
    Commented May 16, 2020 at 22:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .