Common Web Security vulnerabilities

Principle to remember: Filter input escape output

SQL injection (user input is not filtered for special characters) 

Example:

1. A form is displayed on a web application that contains some text fields
2. These text fields data are not validated on the client/server side so it lets any data in
3. The data entered is directly used in building an SQL query
4. A malicious user enters some bad data in the text field which contains an executable SQL statement to corrupt the database or display unintended results
5. So, instead of executing "SELECT * FROM products WHERE id_product=$id_product", the application executes "SELECT * FROM products WHERE id_product=$id_product UNION Select * from USERS"

Cross Site Scripting (code injection by malicious to pages used by real users) - this happens when developers do not check the input and let arbitrary data in to the database. Then, this arbitrary data (such as a javascript embedded in script tag)  is displayed on the web page. When a user performs an action on the web page, sensitive data such as sessionId or personal data is sent unknowingly to the malicious web site. This is very similar to SQL injection but instead of sending SQLs in text fields, a text containing script tag is sent to the server side to be stored in the database only to be displayed later.

Example:

1. A real website displays a form containing name etc.
2. Since there is a bug in the server side code, it lets any text to be entered in the text field
3. A malicious user enters a text which contains some javascript embedded in script tags
4. The server side application persists this data into database
5. The application has a web page that displays a list of all names
6. When a real user retrieves this webpage, it displays the names but also executes javascript
7. When the user submits or performs some action on this webpage, it sends cookies etc to a malicious website.

CORS - Cross Origin Resource Sharing

CSRF - Cross Site Request Forgery
This attack happens if a user does not logout from a good website. Say for example, a good website transfers money using this URL: amount=100.00&routingNumber=1234&account=9876

A evil website may have HTML code with hidden input fields for amount, routing number and account. It may have an image that says "Win MoneY" which when clicked will submit the hidden form fields to the URL for the good website. Since the user is already authenticated and forgot to logoff, the transaction will be executed without the user knowing about it.

One solution is to use the Synchronizer Token Pattern. This solution is to ensure that each request requires, in addition to our session cookie, a randomly generated token as an HTTP parameter. When a request is submitted, the server must look up the expected value for the parameter and compare it against the actual value in the request. If the values do not match, the request should fail.

We can relax the expectations to only require the token for each HTTP request that updates state. This can be safely done since the same origin policy ensures the evil site cannot read the response. Additionally, we do not want to include the random token in HTTP GET as this can cause the tokens to be leaked. So, the new URL looks like this:
amount=100.00&routingNumber=1234&account=9876&_csrf=

You will notice that we added the _csrf parameter with a random value. Now the evil website will not be able to guess the correct value for the _csrf parameter (which must be explicitly provided on the evil website) and the transfer will fail when the server compares the actual token to the expected token.

https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html

If you are only creating a service that is used by non-browser clients, you will likely want to disable CSRF protection.

Improper identity and access management

- forget password mgmt features

Not implementing API keys for clients

Denial of service

- flooding a website/webservice with requests so that legitimate users can't use it