I'm new to web programming and am really upset about the security precautions that should be taken into account while launching a website.If I plan to read analyze and learn every security threats that happened it would take about 2-3 years to acquire good knowledge in this field.I have a little knowledge about security issues from reading OWASP guide.While reading I realized that every security issue is due to poor content validation of input to the server.What I mean is, if I manage to write codes in the server side that perfectly deploy content validation on every HTTP request (POST,GET..etc )and filter the right ones and block the unwanted or suspicious ones,can I get rid of all these security attacks and breaches ?

  • 1
    It really should not be surprising that it will take a few years to become knowledgeable in information security; that's pretty standard for any field! Dec 21, 2016 at 16:51
  • 3
    You say you're new to web programming, what did you expect? It takes a lot of effort and time to learn to develop secure code. As a developer you don't need to "read analyze and learn every security threats", you need to learn best coding practices for what you're doing and consult a security expert for posible threats
    – Mr. E
    Dec 21, 2016 at 18:11
  • 1
    one could argue that all attacks are the result of not handling input correctly; after all, without input there would be no attack. The problem is that we tend to think of input validation a snapshot process, and not as a piece of a larger context; while a single ping might be harmless, 1,000s are not. As a result, our forest is less secure than the trees. Analogy: a security camera operator might not raise the alarm about someone in a phone company van messing with the building's wires because at a glance it appears legit.
    – dandavis
    Dec 22, 2016 at 3:20
  • 1
    'a website of my own as quickly as possible' -- what would the site do? A static HTML site is unlikely to be hacked (do you also want to set up the hosting, though?). For the rest, as they say... cheap, quick, secure -- choose any two.
    – LSerni
    Dec 22, 2016 at 9:44
  • 1
    @neo Sure, path traversals are due to vulnerable frameworks or missconfiguration, exploits against vulnerable underlying software such as OS/web servers/frameworks, session hijacking vulnerabilities that derives into unathorized access, DoS, etc. Also the employees could be targets for phishing attacks to get access to information in your application, arguably is an attack against your application but doesn't go through your application at all
    – Mr. E
    Dec 22, 2016 at 12:56

4 Answers 4


No, you will never completely immunise yourself against all potential security attacks and breaches. Validating input is a significant step in defending your assets though in terms of reducing the possibility of SQL injection and XSS. Read the OWASP top ten again - it's a good place to start.

Try and ask more specific questions about attacks or countermeasures and defences and you will receive more helpful and specific replies.

  • thanks for your answer.But can you help me to correct my belief by pointing out an attack that doesn't come under poor content validation ? forget brute force I don't consider that as a security attack
    – user134080
    Dec 22, 2016 at 7:01
  • 2
    OK, let's assume everything below layer seven is sorted - you are not vulnerable to dns / arp / mac spoofs, dos etc. If you validate input and remove xss, script injection and sql injection threats, you may still be vulnerable to Bad session management / broken authentication Security misconfig - can people get to your config files, do they have passwords in, can they get to your admin interface? How about CSRF tokens, direct object references for account numbers / order numbers? Do you check authentication on every request to a resource?
    – iainpb
    Dec 22, 2016 at 9:09

You will be able to get rid of many of them, undoubtedly.

But, on the one hand, some vulnerabilities stem from your architecture. In a sense you might say that your application is designed to be unsecure.

Suppose your logout code does not properly destroy the session, but leaves it in a state that is recognized by the login page as being "logged out". Apparently, everything works fine. All the tests pass. There is one test missing which would have faiiled - trying to access a resource after logout. But the test is missing.

If you open two tabs in the same browser, you might discover that you can logout from the first page, and still be able to navigate through the site using 100% regular requests, passing all validations; and being officially logged out, everything you do is not recorded - all recording attempts crash silently. Your browser console log fills with errors, and you don't care.

And it's even worse than that. If you try to access a superadmin resource, the system tries to verify whether you're authorized or not, and due to the unforeseen circumstance of you no longer having a User entity mapped server side, this check fails. In such a way that this session is now granted superadmin access.

So you are left with an application where perfectly legal inputs, simply coming from two different tabs of the same browser, end up granting you full administrative access to the application, and someone can pwn it unwittingly.

And when this happened, because it really happened, the "solution" proposed was, you guessed it, trying to find a way to prevent two tabs opening in the browser instead of tracing the source of the problem. The "real" solution was to add one line with session_destroy() in the source. The "quick patch" turned out to be a week's worth of kludgy Javascript nightmare.

Another example is weak randomness or information disclosure in your application, that might allow someone to guess how to gain unwarranted privileges. They will do so by issuing legal commands - the problem will be that they were able to discover these commands.

For instance, some applications may supply a menu with options. An admin-level user will be shown ten entries, a guest will be shown only two. The links to the privileged entry points will not be in the HTML. But if the user privilege level is not checked by those entry points, anyone can access them provided he knows or guesses their names.

Predictable password-reset nonces (e.g. md5(loginname + unix_timestamp) ) will allow a malicious user to access any account by sending a password-reset request late at night, and sending blindly one confirmation (or a reasonable number of bruteforce attempts). The legitimate user will discover this the morning after, and it may be too late.

Resetting the password before the confirmation arrives, and using the latter to grant access, will result in easy denial of service of all accounts.

And, of course, we could find many more examples at several levels of vulnerability (from accessing unauthorized data to disrupting site operation) that will still work even after all possible sanitizations.

On the other hand, properly sanitizing inputs might turn out to be impossible, for you might need to process impossibly complex input combinations or be unable to easily tell whether, say, inputing COTE D'OR is a legitimate request or a SQL injection attempt (in this case yes, it is reasonably easy).

In some scenarios you would need a secure interpreter of the input to be able to tell whether the input is kosher or not... but if you had such an interpreter, it would make more sense to use it to parse input data in the production code. This kind of "shielding" is still worthwhile when you can not modify the application behaviour, and are forced to deploy a cleverer "front end" as a shield; but as a web app developer for apps of your own, this is not your case.

My advice is to carefully plan and test your application and try to think about everything which could possibly go wrong and what to do when it will finally go wrong.

Enforcing a "Great Wall" of sanitized input might lull you into a false sense of security, and in the long run, do more harm than good.

That said, there are several libraries and frameworks that will add input sanitization at next to no cost, and it's undoubtedly a road worth pursuing. What it is not is a "silver bullet" that allows you to "get rid of all the vulnerabilities".

  • thanks for your reply...but when i logout from one tab the cookies will get destroyed.so even if I send a xhr request from other tab and if i properly code to validate every request with cookies validation I can identify the person is logged out right ?I know content validation is not a silver bullet but I can get rid of 90% of attacks right ? can you please show an attack reported that is not due to poor content validation?if so i can correct my belief
    – user134080
    Dec 22, 2016 at 7:17
  • "when i logout from one tab the cookies will get destroyed" -- no; this is something you must implement, and is independent from content validation (also, how cookies are shared between tabs depends on the browser).
    – LSerni
    Dec 22, 2016 at 9:30

Yes, properly executed content validation will lay the foundation for a robust security approach. The OWASP Top 10 is a guide for establishing a baseline security posture.

No, content validation is not a golden rule to prevent ALL attacks and breaches. While establishing a solid implementation of content validation will drastically reduce the number of successful attacks, but "there's more than one way to skin a cat."

You must also consider the risks and impact that a breach might create. A personal website may not have much impact, and a breach can be solved by a simple restore from backup. A website dealing with financial or health information could have major implications from a single breach.

You, as a new web-developer, do not necessarily need to be intimately familiar with all attack and defense methods, but you should at least be familiar of the basics of how to correctly protect your websites. As time goes on you should continue to develop your knowledge of defensive mechanisms.

If the idea of learning how to defend against attacks upsets you, you may unfortunately be in the wrong field. In this day and age, knowledge of security best practices is becoming more and more important.

  • thanks for your reply...can you help me with some sites that is good for beginers to learn basic protection schemes ? also can you please show an attack reported that is not due to poor content validation?if so i can correct my belief
    – user134080
    Dec 22, 2016 at 7:20

I don't think that it is a good approach to dive into "content validation" to secure your website. Instead, you should use frameworks and technologies which avoid many risks from the start. When talking about SQL injection, don't use any content validation, use prepared statements. They exist in Java, they exist in PHP. Never ever compile your statements yourself by string concatenation. That's it.

Then, you must think about XSS and cross site request forgery. It is a good idea to think about which pieces of the user input are reflected back into your http response to the browser. However, instead of writing functions yourself that parse the user input (you will most probably miss something) html-encode the output or use a framework that does so for you. It is not a bad idea to understand the most common attack vectors regarding XSS. You should know that there not only injections of the type <script>alert('sth')</alert> but also stuff like onload=... which avoids the characters < and >.

Check the OWASP pages for CSRF. One relatively easy way to make CSRF a lot harder is to check the referrer when you process requests and reject if the referrer is not your own site.

That said, input validation is definitely a must when you know that an input has a precisely defined format. Good example is a date. Make sure the user really enters a date. This will improve the quality of your code regardless of security.

A couple of more things:

  • Don't use code execution. No eval, exec, whatever they're called in your language
  • Don't use serialization. Never deserialize objects a client sends you.

You must log in to answer this question.