The responsibility for securing a website lies with its owner. If personal data is lost as a result of a phishing attack, xss, etc., any complaint will be directed against the owner of the platform, and the GDPR fines are not small.  

When customers use an online credit card payment processor, they need to know that their data is secure. Visitors do not want their personal information to fall into the wrong hands. Whether you own a small business or a business, users expect a secure online experience. 

The minimum security starts from using a secure domain / subdomain with an SSL certificate, a server with secure VPN access to a trusted hosting provider, password security policies requiring administrators at least 13 characters with different validation conditions and a platform which allows users to perform the desired actions, but limits malicious actions. We can divide the measures into two categories: server-side security and application-level security. Each vulnerability can have a different degree of risk - from a minor one, where the attacker cannot get too much, to a critical risk - in which the attacker can take control of your platform, the databases hosted on your server, etc.

  Attacks on the server side try to compromise and steal data from databases and applications, emails or any other content on a server, and attacks on the application side, email accounts, etc. are quite common and every website owner must make sure that he takes all necessary measures to protect the web platforms available online. 

SQL, OS, XXE, or LDAP injection 

is a web security vulnerability that allows an attacker to interfere with queries that an application is making to the database. In general, it allows the attacker to view data that they would not normally be able to access and certainly should not be able to access, such as personal data belonging to other users: bank accounts, last name, first name, emails, phone numbers. phone, sent messages and any other personal information that is stored through the use of the website. 

These queries by the attacker can give him control of the database behind a web application. Attackers can use SQL Injection vulnerabilities to circumvent application security measures and can identify the authentication and authorization of a web page or web application. I can also use SQL Injection to add, edit, and delete records from the database. 

How is this type of attack prevented? The only surefire way to prevent SQL Injection attacks is to validate database entries and parameterized queries, including queries prepared and executed later. The application code should never use direct insertion. The developer must sanitize all data entries, not just data submissions through web forms, such as authentication forms. They need to eliminate any potential elements of malicious code (such as single quotes) by systematically sanitizing each type of content. It is also a good idea to disable the display of database errors on the website published in production. Database errors can be used with SQL Injection to obtain information about the database.

The 3 most important rules to prevent one of the most disastrous attacks on a platform are: 

• NEVER trust a user's input

• using the latest technologies - PHP 7.4 and the latest version available for the database, the latest plugins or software if you use a CMS product (WordPress, Joomla, etc.)

• scans the web platform rigorously - there are many providers that ensure you test the web platform, but our preferred solution is Detectify, an intuitive platform that ensures very varied and effective vulnerability tests, with easy-to-understand reporting and actions easy-to-implement detailed to eliminate identified problems.

SPAMs

 coming from the contact form or from the comments allowed in the blog area or other pages are one of the simplest means of web appeal. Not only will the lack of anti-SPAM protection negatively affect users' trust in your website, but even Google will penalize your website in terms of SEO. Use a system to check if the user is 'human' or not to protect yourself from this type of attack.

DDoS or 'brute force' attacks 

work by hitting a website with false requests. In the case of many automatically repeated requests, servers can slow down or even crash, and sometimes even open security vulnerabilities, allowing hackers to inject malicious code. Although both involve repeated requests on a server, brute force attacks are more concentrated, trying to break authentication credentials or expose encrypted data. 

Reputation is hard to build, but can be easily damaged. We recommend a hosting plan protected against such attacks - you can choose any NSHOST hosting plan where security is the priority of the team of specialists. 

 XSS attacks

are another tactic that hackers use to damage and compromise websites through this cross-site scripting to send a malicious script to a user who suspects nothing. The end user's browser has no way of suspecting that the script is untrusted and will execute it. Because it believes that the script comes from a trusted source, malicious code can access any cookies, information stored in sessions or other sensitive information saved by the browser and used with that website. These scripts can even rewrite the content of the HTML page. 

We recommend that you check all the recommendations in this XSS prevention checklist.

There are many other types of attacks and vulnerabilities that every website owner needs to identify in a timely manner and ensure their prompt repair. We remind you of the importance of a regular scan to identify these vulnerabilities. 

 Backup. Backup. Backup

A hosting provider will provide you with an automatic, incremental backup service, so that you do not waste valuable time for this activity. What matters here is both the frequency and history of the backup, as well as its location. The period and frequency of backup that is at the choice of each website owner: from a daily backup with a minimum of 5 days history on the same server - up to 365 days of daily incremental backup that is secured on a different server than the one where the website is published. The longer the backup period is and the longer the developer ensures a complete and well-structured log, the more the owner of an attacked website will be able to restore a version of the application unaffected by a hacker and will be able to find the traces of the attack suffered. We recommend using a different server for backup, protecting your content if an attacker manages to access the primary server.