Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

I'm wondering what are the top priority security checks you should make befor launching a new webapp?

I'm guessing brute force vulnerabilities and cross-site scripting. What are the other things you absolutely have to check even if you have no time for it?

share|improve this question
If it touches a SQL-based RDBMS: SQLi; LDAP store: LDAPi; Local files: RFI/LFI/CMDi; XML/XPath/XQuery stores: XPATHi; File upload functionality needs to be checked, Authentication is probably #1 – atdre Nov 16 '10 at 14:53
Also: this is highly dependent on the language, framework, use of 3rd-party/external/contrib components, certain framework or developer features/patterns, use of VM, perhaps even OS level configuration, and many other factors such as the style, capabilities, and biases of the app developers – atdre Nov 17 '10 at 22:05

5 Answers 5

up vote 14 down vote accepted

OWASP has so called Top Ten Project, that shows which the most popular vulnerabilities are. But you should never limit yourself only on those checks that are listed there. I never liked how it sounds - "show me top 10 vulnerabilities". Quite similar answer is here:, in the mean of philosophy. The first paragraph fully expresses my opinion. Let me cite:

If your intention is to write secure code, then I would recommend to avoid such questions like "top10 vulnerabilities". There is no point in focusing only on some desired sort of bugs, because there are quite similar chances to introduce bug of typecasting, integer overflow, off-by-one, stack overflow and others if your knowledge in C/C++ is weak and you have small experience in programming.

share|improve this answer

The most important threats are the ones that attempt to access the backend, like database. SQL injection is on top of the list; the check you need to do is to make sure that the user input is not directly fed into the string for a dynamic query; the user input is anything that is coming from the client; even if the user is not able to edit it in the form or on the browser, imagine that they can intercept the traffic leaving their browser and inject anything into any field. So always keep in mind: "do not trust input coming from client".

So by not trusting the user input, now you have to validate every input; for SQL injection, you need to scrap any character that is not accepted; e.g., if the user is supposed search a number, do not accept anything except a combination of 0-9 to a certain length; remove the rest and then feed it into the query. It is a good idea to avoid dynamic queries altogether and use parameterized queries and stored procedures in the database.

The next top attack is injections that can target other users; like XSS. The story with XSS is similar to SQL injection, you should not trust user input, and do a whitelist validation upon receiving any input. In general, client side checks to make sure the format the user typed the data is not enough, and everything must be rechecked again at the server side.

You have to pay extra attention to authentication part; username and password entry seems like an easy functionality; it is not. You need to make sure upon successful login, a new session value is generated, and set at the client's cookie. You also need to make sure for the rest of the time the user is logged in, this session is not exposed over HTTP; i.e., you got to go over SSL. The session must be random, long enough, and non guessable. Most of the programming languages can take care of that; do not reinvent the wheel. Make sure the session has Secure and HTTPOnly flags set; and make sure it gets expired after an idle time or manual log out. Password reset and change are also very sensitive functionalities; which needs a long post to discuss.

A very important part is authorization. Once a user is authenticated, it does not mean you are done; each user should only access certain pages or data; thus every request must be checked at the server side to prevent privilege escalation.

share|improve this answer

I think Ams has it right, however in terms of your greatest exposure, it is worth looking at the statistics. Check out the Verizon Data Breach Report, the Krebs Java Security Report and the WHID Security Report for some great sources of information on what attacks are really happening on the Internet.

share|improve this answer
There is a short overview of the WHID Security Report on this blog (…) – David Stubley Dec 2 '10 at 20:23
Of course - I should have popped that link up David. – Rory Alsop Dec 2 '10 at 20:29

If I were really critical on time I would make sure my application is checked for the following:

  • Input sanitation! Find a good library to clean your data before they are used by the underlying system. XML-, SQL-, Html-, Command-injections are so dangerous!
  • CSRF
  • Uploading possibilities need focus on not allowing path traversal and uploading malicious scripts which is parsed by the server

I would care for "brute forcing" abilities. Ofcourse users need strong passwords, and also directory structure and files can always be bruteforced. Remember that security by obscurity does not work alone :)

share|improve this answer

SQL Injection is a big one if you have any sort of database interaction, and is relatively easy to test for. Cross-Site Request Forgery (CSRF) is another one that I don't go without. It's also a good idea to check for file canonicalization attacks, especially if you support user uploads or downloads of any kind.

The rest really depends on your app, the type of data it contains and who the users are.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.