That question might sound trivial to many people, but when looking at how websites are secure today, that question seems to make sense…
What are the main priorities for a “typical” web developer? Functionalities, no bugs in a normal use of the application and sometimes the beauty of the code itself (having a well designed code architecture, performance…). The website must first fit the functional and technical requirements, which includes tons of aspects that will be directly visible to the client: functionalities, design, performance, SEO, analytics , ergonomics and so on…

But who from the client, from the marketing team, from the consultant, from the “project manager” or from any other stakeholder will tell the developers: “I want a secure website, don’t leave any vulnerability in it”?
It seems to be obvious to everyone: the website will be secure enough and nobody will break it. By the way, don’t you think it would be kind of an offense to the developers if we ask them not to create vulnerabilities? Moreover, who would have the idea to attack our website? Why us? We are not a bank and we are even basing our developments on an open source framework!

What we see is that there are tons of reasons to forget about security and to hide these tricky questions under the carpet.

Let’s be very clear: you don’t need to be a genius to discover and exploit a vulnerability on a website. The methods and tools required to do this are really easy to find on the internet, in books or magazines, along with detailed examples.
The fact is, web developers are just like any other developer: sometimes they make mistakes. If they are lucky, their mistakes will cause their application to crash and sometimes to give back some bug information back to the user. If they’re unlucky, their mistakes create a security hole in their application.

But why the hell would someone try to attack my website?
Answers to that question are as numerous as reasons to forget about security: stealing users authentication credentials (login, email, password), stealing personal data, damaging a brand by defacing the website or by injecting bad content, performing fishing attacks, redirecting users to a malicious website… once again, the list is really long and grows continuously.

But what would motivate such an attacker?
Stealing your users’ emails will allow attackers to spam them, to realize phishing attacks, to steal more sensitive data later on during subsequent attacks or even to perform quite diverse actions without their knowledge once they’ve go the password. Exploitation possibilities are innumerable and only have the attackers’ imagination as a limit, motivated by financial profits, by pure maliciousness, or even by the adrenalin that hacking provides (yes it does).

OK fine, but in my very personal case, what are the real risks?
The risks obviously depend on what data your application contains, and on what functionalities it has. Security is a tradeoff, and consists of protecting data, functionalities and users or consumers, with a security level that fits risks. A security audit like VAADATA provides allows you to make a status on these items that you should care about.
Security breaches can be of many kinds, starting with logical flaws (like an e-commerce website that would wrongly allow someone to add items in the basket after the payment authorization has been processed and before the order is finalized), or with technical flaws like code injection and many others.

How can I ensure that the website I developed is secure enough?
First things first, web security should starts during the application design phase: a security-focused review should be performed to detect logical flaws. Security must also be part of the development lifecycle, at least by performing security-focused code reviews. Before pushing the website to production, a final test must also be performed in order to detect vulnerabilities that might have been skipped.
A web application penetration test can be performed at any time so as to have a clear vision of the website’s security and to list breaches to be fixed.