Using HTML5 for client-side form validation

user4035 :

The only issue is that these attributes can be ignored by some browsers. And javascript will work everywhere if enabled.",

2015-07-25T14:21:23

het.oosten :

The html5 validation is only for a better user experience, and not for security. You already triggered that by using server side validation, using PHP.\n\nFor your server validation design, it makes no difference whether you use HTML5 validation or not.",

2015-07-25T14:20:53

rohankvashisht :

Well, here is a list of top 10 Website Security issues.\n\n\nOut of which HTML5 attributes can handle only 1st one. While php can take care of 2,3,4,5,7 and 10.\n\n\nAlso keep in mind, as user4035 mentioned that HTML5 attributes are not supported by old browsers.\n\nYou should use double validation of your data. Because many times people disable JavaScript in their browsers. Then only server side validation with php will save you. So, you must validate your data with HTML5 attributes(as much it's possible with them)because it's easy with it, then you validate it with JavaScript also and don't forget to validate it with php as well. Now, our data is validate for all types of general consequences.\n\n\n\n1.\nValidation of input and output data :\n\nAll data used by the website (from users, other servers, other websites \nand internal systems) must be validated for type (e.g. numeric, date, \nstring), length (e.g. 200 characters maximum, or a \npositive integer) and \nsyntax (e.g. product codes begin with 2 letters and are followed by 5 \ndigits) and business rules (e.g. televisions can only cost between £100 and \n£2000, an order can contain at most 20 items, daily\n credit limit must not \nbe exceeded). All data written as output (displayed) needs to be safe to \nview in a browser, email client or other software and the integrity of any \ndata that is returned must be checked. Utilising A\nsynchronous JavaScript \nand XML (AJAX) or Adobe Flex increase complexity and the possible attack \nvectors. \n\n\n2.\nDirect data access (and theft) :\n\nIf data exists, it can potentially be viewed or extracted. Avoid storing \ndata that you do not need on the website and its database(s) – for \nexample some data relating to payment cards should \nnever be stored.\nPoorly developed systems may allow access to data through SQL injection \n Top 10 \nWebsite security issues \n2\ncompromises, insufficient input and output data validation (see No 1 \nabove) or poor system security. \n\n\n3.\nData poisoning :\n\nIf user’s can amend or delete data inappropriately \nand this is then used to \nupdate your internal systems, business information \nis being lost. This can \nbe hard to detect and it is important that the business rules are examined \nand enforced to validate data changes to ensure poisoning is not \noccurring. If poisoning is not detected until well\n after it has occurred, it \nmay be impossible to recover the original data. \n\n\n4.\nMalicious file execution :\n\nUploaded files or other data feeds may not be what \nthey seem. Never \nallow user-supplied input to be used in any file na\nme or path (e.g. URLs or \nfile system references). Uploaded files may also contain a malicious \npayload so should not be stored in web accessible locations. \n\n\n5.\nAuthentication and session management :\n\nWebsites rely on identifying users to provide access permissions to data \nand functions. If authentication (verification of \nidentity, registration and \nlogging in), authorisation (granting access rights)\n and session management \n(keeping track of the identity of a logged in user \nwhile they browse a \nwebsite) can be circumvented or altered, a user could access resources \nthey are not allowed to. Beware especially of how password reminders, \nremember-me, change password, log out and updating \naccount details are \nhandled, how session tokens are used and always have login forms on \ndedicated and encrypted (SSL) pages. \n\n\n6.\nSystem architecture and configuration :\n\nThe information system architecture model should address the sensitivity \nof data identified during the requirements and specification phase of a \nwebsite project. This may entail having separate web, application and \ndatabase servers or involve clustering, load balancing or virtualisation.\nAdditional security issues can be created through t\nhe way the live \nenvironment is configured. Sufficient and safe logging, monitoring and \nalerting facilities need to be built in to allow audit. \n Top 10 \nWebsite security issues \n3\n\n\n7.\nPhishing :\n\nPhishing, where users are conned into believing some other entity is or \nbelongs to your own organisation (email messages and websites are the \nmost common combination), is best tackled through user education but \nthe way the website is designed, its architecture and how it \ncommunicates with users can reduce the risk. \n\n\n8.\nDenial of service :\n\nWhilst malicious users might try to swamp the web server with a vast \nnumber of requests or actions that degrade its performance (filling up \nlogs, uploading large files, undertaking tasks that\n require a lot of memory \nrepeatedly) denial of service attacks include locking out valid user \naccounts or be caused by coding problems (e.g. memory leaks, resources \nnot being released). \n\n\n9.\nSystem information leakage :\n\nWeb servers, errors, staff, partner organisations, \nsearch engines and \nrubbish can all be the source of important information about your website \n– its technologies, business logic and security met\nhods. An attacker can \nuse such information to their advantage so it is important to avoid system \ninformation leakage as far as possible. \n\n\n10.\nError handling:\n \nExceptions such as user data validation messages, missing pages and \nserver errors should be handled by the code so that\n a custom page is \ndisplayed that does not provide any system information to the user (see \nNo 9 above). Logging and alerting of unusual conditions should be \nenabled and these should allow subsequent audit. \n\n\nReference: Click Here",

2015-07-25T14:44:35