Difference between revisions of "Good v. Bad Web Development"
(Created page with "==Preface== Web development in contrast to web design refers to the actual technologies and methodologies the specific website or web platform uses to ==Use GET Responsibly=...") |
|||
| Line 2: | Line 2: | ||
Web development in contrast to web design refers to the actual technologies and methodologies the specific website or web platform uses to | Web development in contrast to web design refers to the actual technologies and methodologies the specific website or web platform uses to | ||
| − | ==Use GET Responsibly== | + | ==HTTP Method Security== |
| + | |||
| + | ===Use GET Responsibly=== | ||
<div style='text-align: center;' align='center'> | <div style='text-align: center;' align='center'> | ||
<div style='padding: 20px; border: 1px solid black; font-family: Monospace; background-color: black; color: white;'>include($_GET['page']); | <div style='padding: 20px; border: 1px solid black; font-family: Monospace; background-color: black; color: white;'>include($_GET['page']); | ||
| Line 16: | Line 18: | ||
</div> | </div> | ||
| − | If you accept input into your application or site through GET variables, do not use them directly, doing so can open your infrastructure to all kinds of attacks, such as through includes, you can get people injecting remote code or accessing system configuration files. | + | If you accept input into your application or site through GET variables, do not use them directly, doing so can open your infrastructure to all kinds of attacks, such as through includes, you can get people injecting remote code or accessing system configuration files or leveraging your site to execute Cross-Site-Scripting attacks where a user may click on a link to your site crafted to cause them to perform an act improperly. |
| + | ===Use POST for Submission of Actions=== | ||
| + | If you have your users logging in, posting messages, submitting a transaction, deleting a wiki page or something, do not use GET, ever. Use the POST method, it is specifically designed for form processing amongst other things. If you use GET, it can effectively embed potentially sensitive information into the user's browser history like usernames and passwords in plain text which is hazardous to your site security. Implementing this strong recommendation also prevents search engines and similar crawler bots from performing actions on your website that may lead to undesirable results such as pages getting altered. | ||
| − | + | The exception to this rule is search results. If a user is using a search box, that can be GET as so the user can click their back button between pages without warnings about "submitting the form twice" or to make it easy for the user to share searches with other users. | |
| − | If | ||
| − | ==Cookies== | + | ==Javascript== |
| + | |||
| + | ===Javascript is not a Requirement=== | ||
| + | <div style='text-align: center;' align='center'> | ||
| + | Don't do this... | ||
| + | <div style='padding: 20px; border: 1px solid black; font-family: Monospace; background-color: black; color: white;'> | ||
| + | a href='#' onclick='somefunction()' </div> | ||
| + | |||
| + | Do this... | ||
| + | <div style='padding: 20px; border: 1px solid black; font-family: Monospace; background-color: black; color: white;'> | ||
| + | a href='/somescript.php?action=somefunction¶meter=1' onclick='somefunction()' </div> | ||
| + | </div> | ||
| + | |||
| + | |||
| + | If you are developing a site, use javascript only as an enhancement, not as a requirement, if you have an onclick handler, also set an href that does something useful for that link. It is often a belief that javascript is a requirement by the web development community because of the features it provides to make sites behave Sci-fi-like or provide smooth transitions, but at the end of the day, use it responsibly and only when you can offer a substitute. | ||
| + | |||
| + | Consider also: Search engines may not be able to properly index some of your javascript-only content. | ||
| + | |||
| + | |||
| + | ===jquery=== | ||
| + | Like the rest of javascript, jquery should be used sparingly and your site should not depend on jquery's operation. Further, you should evaluate if you need to import the entire jquery library to implement just one feature from it. | ||
| + | |||
| + | ==Privacy== | ||
| + | |||
| + | ===Cookies=== | ||
<div style='text-align: center;' align='center'> | <div style='text-align: center;' align='center'> | ||
<div style='padding: 20px; border: 1px solid black; font-family: Monospace; background-color: black; color: white;'>trackid:8e06d3861932596694527c75e1858346</div> | <div style='padding: 20px; border: 1px solid black; font-family: Monospace; background-color: black; color: white;'>trackid:8e06d3861932596694527c75e1858346</div> | ||
Don't do this... | Don't do this... | ||
</div> | </div> | ||
| − | Do not set cookies unless the user actually logs into your website with a username and password. If your site just offers content without interaction chances are you don't need to set cookies. Setting cookies for marketing or accounting purposes is irresponsible and intrusive to users who may not know about cookies aside from a footnote in a privacy policy (to which it's even more irresponsible to expect a cookie to be set before a user can access your privacy policy). | + | Do not set cookies unless the user actually logs into your website with a username and password, other credentials or explicitly requests something to be saved specific to them. If your site just offers content without interaction chances are you don't need to set cookies. Setting cookies for marketing or accounting purposes is irresponsible and intrusive to users who may not know about cookies aside from a footnote in a privacy policy (to which it's even more irresponsible to expect a cookie to be set before a user can access your privacy policy). |
| + | |||
| + | ===Advertisements=== | ||
| + | Your users understand ads pay for your content or other bills, but if your ads you deploy are intrusive or cluttersome, users will either not visit your site or block them making them pointless anyways. This goes without saying that the advertising industry hasn't had a very good reputation over the past 5-10 years and has been increasingly intrusive to users and often disclaim responsibility or shunt any incidents under the rug when there is a compromise on their advertising platform ("we're looking into it" — but no closure nor public accountability). Keep your advertisements in check and research about the ad network your using to see their history with ads carrying malware. Keep in mind, any ads that serve malware on your site will reflect upon you and/or your organization unfortunately — not the advertising network you're using and even one hour of serving malware can drive away a non-trivial percentage of your users. | ||
| + | |||
| + | ==Optimization== | ||
| + | |||
| + | ===Keep the Number of External Calls Down=== | ||
| + | If your website depends on other websites or web services, try to keep the numbers of those domain-crossing calls down to a minimum, do not call out to every social networking site, or importing a high number of javascript libraries, it can slow down your website and make it difficult to navigate as users have to wait for their browsers to render the page and each additional domain can slow the rendering by seconds which can make websites with many pages unusable. | ||
| + | |||
| + | ===Don't use media technologies for simple content=== | ||
| + | If your content is multimedia in nature, feel free to use media technologies like flash or HTML5 or javascript in some way, but if you're serving text and/or images, you should avoid using such technologies as it's guaranteed that it will slow your website's loading time down. | ||
| + | |||
| + | ===PDFs=== | ||
| + | <a href='http://binaries.crs.digibase.ca/b/b1/Internet-Trust-TDWFB-20140211.pdf'>Don't do this</a> | ||
| + | |||
| + | <a href='http://binaries.crs.digibase.ca/b/b1/Internet-Trust-TDWFB-20140211.pdf'>Do this [PDF]</a> | ||
| + | |||
| + | Warn people when your website links to PDFs, even something as simple as a textual notification should be placed in the link. This isn't only just courteous, but some people have slower computers that may not be able to load up PDFs on a whim, especially given how bloated the most popular PDF software (e.g. Adobe Reader) can be. | ||
| + | |||
| + | ==Security Other== | ||
| + | ===Java=== | ||
| + | First of all, Java is a completely different technology than Javascript. That said, Java should be completely avoided on all but utilitarian web resources where a program needs to be run. Websites where Java qualifies to be run is in the order of 0.0001%. If you think your website absolutely needs Java and can't write a completely technical paper on why it is needed that illustrates what utilitarian need needs filling, chances are you are not a part of that percentage. If you are able to illustrate why it is needed, people should be advised before they enter a java area of your website that Java will be in place. Keep in mind most users have java on a site-by-site basis where the user may elect not to trust you. It isn't anything personal. | ||
Revision as of 06:37, 17 March 2014
Preface
Web development in contrast to web design refers to the actual technologies and methodologies the specific website or web platform uses to
HTTP Method Security
Use GET Responsibly
-or-
mysql_query("SELECT FROM table WHERE id = '$_GET['id']'");
-or-
echo $_GET['item']Don't do this...
If you accept input into your application or site through GET variables, do not use them directly, doing so can open your infrastructure to all kinds of attacks, such as through includes, you can get people injecting remote code or accessing system configuration files or leveraging your site to execute Cross-Site-Scripting attacks where a user may click on a link to your site crafted to cause them to perform an act improperly.
Use POST for Submission of Actions
If you have your users logging in, posting messages, submitting a transaction, deleting a wiki page or something, do not use GET, ever. Use the POST method, it is specifically designed for form processing amongst other things. If you use GET, it can effectively embed potentially sensitive information into the user's browser history like usernames and passwords in plain text which is hazardous to your site security. Implementing this strong recommendation also prevents search engines and similar crawler bots from performing actions on your website that may lead to undesirable results such as pages getting altered.
The exception to this rule is search results. If a user is using a search box, that can be GET as so the user can click their back button between pages without warnings about "submitting the form twice" or to make it easy for the user to share searches with other users.
Javascript
Javascript is not a Requirement
Don't do this...
Do this...
If you are developing a site, use javascript only as an enhancement, not as a requirement, if you have an onclick handler, also set an href that does something useful for that link. It is often a belief that javascript is a requirement by the web development community because of the features it provides to make sites behave Sci-fi-like or provide smooth transitions, but at the end of the day, use it responsibly and only when you can offer a substitute.
Consider also: Search engines may not be able to properly index some of your javascript-only content.
jquery
Like the rest of javascript, jquery should be used sparingly and your site should not depend on jquery's operation. Further, you should evaluate if you need to import the entire jquery library to implement just one feature from it.
Privacy
Cookies
Don't do this...
Do not set cookies unless the user actually logs into your website with a username and password, other credentials or explicitly requests something to be saved specific to them. If your site just offers content without interaction chances are you don't need to set cookies. Setting cookies for marketing or accounting purposes is irresponsible and intrusive to users who may not know about cookies aside from a footnote in a privacy policy (to which it's even more irresponsible to expect a cookie to be set before a user can access your privacy policy).
Advertisements
Your users understand ads pay for your content or other bills, but if your ads you deploy are intrusive or cluttersome, users will either not visit your site or block them making them pointless anyways. This goes without saying that the advertising industry hasn't had a very good reputation over the past 5-10 years and has been increasingly intrusive to users and often disclaim responsibility or shunt any incidents under the rug when there is a compromise on their advertising platform ("we're looking into it" — but no closure nor public accountability). Keep your advertisements in check and research about the ad network your using to see their history with ads carrying malware. Keep in mind, any ads that serve malware on your site will reflect upon you and/or your organization unfortunately — not the advertising network you're using and even one hour of serving malware can drive away a non-trivial percentage of your users.
Optimization
Keep the Number of External Calls Down
If your website depends on other websites or web services, try to keep the numbers of those domain-crossing calls down to a minimum, do not call out to every social networking site, or importing a high number of javascript libraries, it can slow down your website and make it difficult to navigate as users have to wait for their browsers to render the page and each additional domain can slow the rendering by seconds which can make websites with many pages unusable.
Don't use media technologies for simple content
If your content is multimedia in nature, feel free to use media technologies like flash or HTML5 or javascript in some way, but if you're serving text and/or images, you should avoid using such technologies as it's guaranteed that it will slow your website's loading time down.
PDFs
<a href='http://binaries.crs.digibase.ca/b/b1/Internet-Trust-TDWFB-20140211.pdf'>Don't do this</a>
<a href='http://binaries.crs.digibase.ca/b/b1/Internet-Trust-TDWFB-20140211.pdf'>Do this [PDF]</a>
Warn people when your website links to PDFs, even something as simple as a textual notification should be placed in the link. This isn't only just courteous, but some people have slower computers that may not be able to load up PDFs on a whim, especially given how bloated the most popular PDF software (e.g. Adobe Reader) can be.
Security Other
Java
First of all, Java is a completely different technology than Javascript. That said, Java should be completely avoided on all but utilitarian web resources where a program needs to be run. Websites where Java qualifies to be run is in the order of 0.0001%. If you think your website absolutely needs Java and can't write a completely technical paper on why it is needed that illustrates what utilitarian need needs filling, chances are you are not a part of that percentage. If you are able to illustrate why it is needed, people should be advised before they enter a java area of your website that Java will be in place. Keep in mind most users have java on a site-by-site basis where the user may elect not to trust you. It isn't anything personal.
