11 Security tips to protect your website
Tags: cybersecurity, webdev, security
Published: 2022-03-08 16:07:47

You may not think your site has anything worth being hacked for, but websites are compromised all the time. The majority of website security breaches are not to steal your data or mess with you, but instead attempts to use your server as a relay for spam, or to set up a temporary web server, to serve files of an illegal nature, or to mine Bitcoins. You could even be hit by ransomware. 

Bad guys are scattered all over to cause harm and at this point we should take protections as well to stay safe.Today I will tell you a few security tips based on my experience.If you find this helpful,please consider a like.It motivates me to create more.So anyway,let's dive into it.

## **01. Keep software up to date:**
It may seem obvious, but ensuring you keep all software up to date is vital. This applies to both the server operating system and any software you may be running on your website such as a CMS or forum. When website security holes are found in software, people are quick to attempt to abuse them.This applies to dependencies as well.

## **02. Do penetration testing:**
Doing pentesting plays another important role in terms of security.There are a handful of open source available out there to help you.If you are running linux I previously wrote a blog about how to get kali tools on ubuntu based distros, you can follow that to get those tools.There is something called [RapidScan](https://github.com/skavngr/rapidscan).You can use it to scan your site for vulnerabilities.

## **03. Sanitize/Validate user inputs:**
When syncing your inputs with server,before sending the raw data sanitize or validate user input.Let me give you an example,so let's say you take text input and then add that as a comment to that page.If it's basically just like that without validation/verification or so then users can post raw html snipppets,so sanitize it, remove stuff that is unnecessary.

## **04. Watch out for SQL injection:**
SQL injection attacks are when an attacker uses a web form field or URL parameter to gain access to or manipulate your database via SQL statements. When you use standard Transact SQL it is easy to unknowingly insert rogue code into your query that could be used to change tables, get information and delete data. You can easily prevent this by always using parameterised queries, most web languages have this feature and it is easy to implement.

Consider this query:
```
"SELECT * FROM table WHERE column = '" + parameter + "';"
```
If an attacker changed the URL parameter to pass in ' or '1'='1 this will cause the query to look like this:
```
"SELECT * FROM table WHERE column = '' OR '1'='1';"
```
Since '1' is equal to '1' this will allow the attacker to add an additional query to the end of the SQL statement which will also be executed.

You could fix this query by explicitly parameterising it. For example, if you're using MySQLi in PHP this should become:
```
$stmt = $pdo->prepare('SELECT * FROM table WHERE column = :value');
$stmt->execute(array('value' => $parameter));
```

## **05. Beware of Error messages and console logs:**
Logging all the necessary info and error is great for development but make sure it doesn't get shipped to production!! Provide only minimal errors to your users, to ensure they don't leak secrets present on your server (e.g. API keys or database passwords). Don't provide full exception details either, as these can make complex attacks like SQL injection far easier. Keep detailed errors in your server logs, and show users only the information they need.

## **06. Protect against XSS:**
XSS commonly known as cross site scripting.This attack injects malicious JavaScript into your pages, which then runs in the browsers of your users, and can change page content, or steal information to send back to the attacker.You need to ensure that users cannot inject active JavaScript content into your pages.The case here is kind of similar to SQL injection btw.The key here is to focus on how your user-generated content could escape the bounds you expect and be interpreted by the browser as something other that what you intended. This is similar to defending against SQL injection. When dynamically generating HTML, use functions that explicitly make the changes you're looking for (e.g. use element.setAttribute and element.textContent, which will be automatically escaped by the browser, rather than setting element.innerHTML by hand), or use functions in your templating tool that automatically do appropriate escaping, rather than concatenating strings or setting raw HTML content.

## **07. Validate on both sites:**
Validation should always be done both on the client and the server. The browser can catch simple failures like mandatory fields that are empty and when you enter text into a numbers only field. These can however be bypassed, and you should make sure you check for these validation and deeper validation server side as failing to do so could lead to malicious code or scripting code being inserted into the database or could cause undesirable results in your website.

## **08. Use HTTPS:**
HTTPS is a protocol used to provide security over the Internet. HTTPS ensures that users are talking to the server they expect, and that nobody else can intercept or change the content they're seeing in transit.

If you have anything that your users might want private, it's highly advisable to use only HTTPS to deliver it. That of course means credit card and login pages (and the URLs they submit to) but typically far more of your site too. A login form will often set a cookie for example, which is sent with every other request to your site that a logged-in user makes, and is used to authenticate those requests. An attacker stealing this would be able to perfectly imitate a user and take over their login session. To defeat these kind of attacks, you almost always want to use HTTPS for your entire site.

## **09. Hash passwords:**

Let's say unfortunately a hacker got access to the db and passwords,now?
If the passwords are hashed after being salted you are fine else : hell nawh!
Hashing is crypting the password into a one way string so no one could crack it and it can be validated to the input because the same value provides the same string.Salting is an extra layer of security to the hash.Lets say you add "!#$" to the start or end of the value and then hash it ,This way it stays more secure.

## **11. Take precautions when accepting file uploads through your site:**
When anyone has the option to upload something to your website, they could abuse the privilege by loading a malicious file, overwriting one of the existing files important to your website, or uploading a file so large it brings your whole website down. 

If possible, simply don’t accept any file uploads through your website. Many small business websites can get by without offering the option of file uploads at all. If that describes you, you can skip everything else in this step.  

But eliminating file uploads isn’t an option for all websites. Some types of businesses, like accountants or healthcare providers, need to give customers a way to securely provide documents. 
Use the following precautions if need file uploading:

-Create a list of allowed files
-scan files for malwares
-keep upload folder outside of webroot
-use filetype verificaion
-rename files after upload

## **10. Lock down your directory and file permissions:** 
On the Linux, permissions are viewable as a three-digit code where each digit is an integer between 0-7. The first digit represents permissions for the owner of the file, the second for anyone assigned to the group that owns the file, and the third for everyone else.The assignations work as follows:

-4 equals Read
-2 equals Write
-1 equals Execute
-0 equals no permissions for that user

So, a file with “777” (or 4+2+1 / 4+2+1 / 4+2+1) permissions is readable, write-able, and executable by the user, the group, and everyone else in the world.
As you might expect, a file that is assigned a permission code that gives anyone on the web the ability to write and execute it is much less secure than one which has been locked down in order to reserve all rights for the owner alone.  Of course, there are valid reasons to open up access to other groups of users (anonymous FTP upload, as one example), but these instances must be carefully considered in order to avoid creating a website security risk.

For this reason, a good rule of thumb is to set your permissions as follows:

-Folders and directories = 755
-Individual files = 644

**Enough for today,I wanted to write more but my finger hurts and today was exhausting, I will rest for a bit...
SO THANK YOU FOR READING A LIKE WOULD BE APPRECIATED!**
[Buy me a coffee](https://www.buymeacoffee.com/tawhid)