Qualitätssicherung Digitale/Web Projekte

Frontend Code Guidelines

Indentations

For all languages, regardless of complexity or age, it is recommended that soft tabs are used. Soft tabs are where space characters are used rather than tab characters and upon hitting the tab key, your editor of choice should insert four spaces.

Cross-Browser Support and Testing

Generally, it is expected for you to support the following internet browsers (for desktops, tablets and mobiles - where possible):

• Google Chrome (current version plus 1 previous version)
• Mozilla Firefox (current version plus 1 previous version)
• Safari (current version plus 1 previous version)
• Internet Explorer 9+

Please note that the above browsers must be tested on both Microsoft Windows and Apple OS X. Special consideration for Linux machines is not mandatory, however if time permits, is also encouraged.

HTML5

Markup code should adhere to the W3C Standards (http://www.w3.org/TR/html5/) and should be able to pass, at least 90%, validation by the W3C Validation Service (https://validator.w3.org/). We do not strive for 100% as cross-browser compatibility is more important than passing validation tests. It is acceptable for you to write a non-standards chunk of code if the result is beneficial to the goal of supporting different browsers and devices.

CSS

All CSS should be included within each page of your website from an external stylesheet and should never be delivered via inline CSS. Additionally, it is recommended that Print CSS styles are given sufficient attention, especially for content-heavy websites.

JavaScript Functionality and Anchor Links

It is never acceptable to have inline JavaScript embedded within the href attribute of an anchor tag. The negative impact of such inline JavaScript is great and there are no circumstances where it would be acceptable to use it.

Performance Testing in General

All websites and apps should be performance tested before being considered finished. For websites, it is expected that all developers will perform a Page Speed Insights test (https://developers.google.com/speed/pagespeed/insights/) and a GTmetrix Performance Test (http://gtmetrix.com/) and, at a minimum, the website will pass with a score/grade in the top 15%. Thus a score of 85% and a grade of A for the Google-powered and GTmetrix-powered tests respectively are required.

More information can be found here: https://wiki.parasol-island.com/Performance_of_Webpages

Performance Testing of CSS and JavaScript

All CSS and JavaScript code should be written with performance in mind. It is highly recommended to follow the Yahoo Developer Performance Guidelines for Best Practices (https://developer.yahoo.com/performance/).

Images Sprites

Where possible, it is recommended that sprites are to be used for small, similar assets (e.g. icons) to help reduce the overall page weight and lower the number of HTTP requests, thus rendering the page quicker.

Meta/Link Tags

Certain meta tags are not only important for SEO purposes but are of the utmost importance for many disabled internet users, therefore it is highly recommended that you pay close attention to your usage of meta tags. Please refer to the upcoming section titled “Accessibility” for more meta tag-related recommendations.

Often Forgotten or Misused Tags

The following tags are often forgotten or misused, therefore it is recommended that you periodically double-check that you are, in fact, using such tags correctly.

1. Favicon
2. Web Icons (for mobile devices)
3. Basic fundamental tags (Title, Description, Keywords, Robots etc.)

Before going live with a website, it is recommended that you triple-check any usages of the robots meta tag to ensure that you have not configured the attribute to be negative towards SEO.

Facebook / Open Graph Tags

Please ensure that you have not forgotten to include, at least, the following four Open Graph tags in your code:

1. OG:Image
2. OG:Title
3. OG:Description
4. OG:URL

Accessibility

The W3C organization runs the Web Accessibility Initiative (WAI) (http://www.w3.org/WAI/) and it is very much recommended for you to familiarize yourself with this initiative as it will empower you to write code that is beneficial and usable by all internet users, including those with disabilities.

Viewports

For the viewport meta tag, it is very important that you do not set maximum-scale to 1.0 (thus rendering the zoom functionality of the mobile browser inoperable) because you will be inadvertently inflicting undeserved difficulty upon visitors of your website whom may have visual problems.

Fantastic Resources for Improving Accessibility

W3C Checklist of Checkpoints for Web Content Accessibility Guidelines (http://www.w3.org/TR/WCAG10/full-checklist.html)

Compulsory Legal Information

The following legal information is compulsory for the vast majority of websites, including some microsites (e.g. Facebook Tab apps).

In English, the compulsory legal information can be presented like so:

{Firmenname und Rechtsform} {Strasse} {Land}-{PLZ} {Ort} Local Court of {Stadt}, HRB {Nummer} (Verpflichtend, wenn ein Handelsregistereintrag vorliegt) VAT ID No.: DE{Nummer} Telephone: +49 ({Vorwahl}) {Telefon} E-Mail: {eMail Adresse} Managing Director and responsible under Sec. 55 para. (2) RStV: {Name/n Geschäftsführer}

Similarly, in German, the compulsory legal information can be presented like so:

{Firmenname und Rechtsform} {Strasse} {Land}-{PLZ} {Ort} Amtsgericht {Stadt}, HRB {Nummer} (Verpflichtend, wenn ein Handelsregistereintrag vorliegt) Ust-ID Nr.: DE{Nummer} Telefon: +49 ({Vorwahl}) {Telefon} E-Mail: {eMail Adresse} Geschäftsführer und inhaltlich Verantwortlicher gemäß § 55 Abs. 2 RStV: {Name/n Geschäftsführer}

Copyright Information

Please refrain from hard-coding the year value within the copyright notice; instead, please utilize auto-updating functionality. For example, with PHP, you could perform the following:

© <?php date("Y"); ?> {Firmenname}. Alle Rechte vorbehalten.

Search Engine Optimization (SEO)

After all of the hard work that you have invested in your code, it is very much recommended for you, when you have finished your project, to double-check that your website has a working, up-to-date sitemap so that your hard work is not negatively affected by badly-performing SEO performance.

Additionally, it is recommended to manually submit the URL of your website to Google via http://www.google.com/addurl/?continue=/addurl even if your website is already listed in Google SERPs.

As a developer, it is often quite easy to overlook the markup hierarchy of a page. Therefore, it is recommended for you to perform a post-development examination of all important tag usages. For example, ensure that heading tags (

,

etc.) have been used in a sensible manner.

Google Webmaster Tools

Please ensure that your website has been correctly setup and configured with Google Webmaster Tools and that the access to this account has been shared with the Project Manager of your project.

Error Pages

Please ensure that your website is correctly configured, and tested, to produce relevant error pages and codes for situations such as 404s and 401s. In absolutely no circumstances should the user be presented with a blank, white page.

Privacy

Almost all websites should be operable via an SSL, encrypted, connection. If your website is not utilizing an SSL certificate and you are obtaining information from your visitors, please speak with your Project Manager to discuss a plan to fix this as all private and confidential user information must be transmitted safely and securely.

Open Source Rules!

At Parasol Island, we truly believe in the open source movement and, as such, follow what we like to call, The Open Source Rule. This rule depicts that all frontend-related tools be free of charge and available for everyone to use.

If, under very special circumstances, you find yourself needing to use a paid tool or service, you must ensure that the license is applicable to both yourself and Parasol Island (at no extra cost). If this is not possible, please speak to your Project Manager as a matter of urgency.

Backend Code Guidelines

Wordpress Admin / phpMyAdmin / Other Administrative Control Panels

If your website is utilizing the ever-popular phpMyAdmin software or any other limited-access, administrative control panels (be it for databases, users, content etc.), please ensure that the path to such a feature does not include keywords that are commonly used across the internet. Usage of such common keywords will negatively impact the safety and security of your website.

For example, it is never acceptable to use the following keywords in the URL:

1. phpMyAdmin
2. admin
3. administration
4. wp-admin
5. secure

It is highly recommended that you utilize random, complex strings for accessing security-sensitive areas of your website.

Additionally, it is recommended for all security-sensitive directories to utilize .htaccess/.htpasswd files to integrate a two-step verification process.

Web Servers

General

NGINX or LightHTTPD is very much preferred with only ports 80 and 443 open by default; all other ports should be closed. Please also ensure that FTP access is disabled.

SSL

All personally-identifiable and confidential information obtained from visitors (via any means) must be transmitted through a correctly-configured SSL connection using a validated and active SSL Certificate.

Database Encryption & Decryption

All identifiable information that is to be stored in a database (or any other method of storage) must be encrypted at source and decrypted when needed.

Multiviews

Multiviews must always be disabled.

Database Servers

Where possible, a project should utilize a dedicated database server which has a very tightly controlled firewall configured. Ideally, the firewall would only permit connections to be made to the database server from your project’s web server, thus making the database server inaccessible to the rest of the world.

PHP

Environment

By default, PHP should be operating in Safe Mode and allow_url_fopen should be Off. Additionally, passwords should not be stored in cleartext within the PHP files containing business-logic. Passwords and other security-centric data should be stored in an external configuration file and stored in a non publicly-available location (outside of the server’s web-root).

User Input, Sanitization and XSS

Any information obtained from visitors must be sanitized and stored securely. Under the vast majority of circumstances, you should strip all tags from visitor input. Where possible, the visitor’s inputted data should not be entered directly into the database (or any other method of storage). For example, if you have a gender <select> element where only Mr, Mrs and Miss are the potential options, it is recommended that you compare the visitor’s input and then store your own value into the database. This approach of comparing and accepting, results in much safer input handling as you are able to better govern acceptable user values.

Additionally, it is critical that you only utilize user-sourced data within contained and controlled environments. For example, if you are running a competition to guess the number of balloons in a box, not only should you check that the user’s submitted guess is of numerical value before storing it in a database and that the accommodating database field is of an integer-based field type, but you should also force any future variables which handle the guess data to be of an integer-based type, too.

This two-staged governance approach provides much more protection against dangerous XSS attacks than simply accepting and using any type of data.

CSRF (Cross-Site Request Forgery / “Session Riding”) Attacks

If your websites accepts data or actions from its visitors, you must protect against CSRF attacks by utilizing CSRF session tokens or cookies (or both). If you are not familiar with CSRF attacks, here is a simple example that illustrates the danger of such attacks:

CSRF Example

Imagine your website requires its visitors to create a premium (paid) account in order to access special content. As the developer, you have created a file named delete-account.php because, quite rightly, you are aware that users of your website should always have the option of deleting their own accounts. This sort of innocent functionality can easily be abused by an CSRF attack if you do not protect against it.

How? Quite simply, an attacker could create a link on a popular forum, that many of your visitors use, that links to your delete-account.php page and once the user clicks on the unsuspicious forum link, they suddenly find themselves with a deleted account on your website.

Protection Against CSRF Attacks

The simplest and easiest way to protect your website against a CSRF attack is to create a unique session variable when your visitor first visits your website and whenever they want to perform an account (such as creating or deleting an account), you send this unique identifier along with their request (be it via a hidden input, query string value etc.) which you can compare against the value stored in their session variable. If the two values match, go ahead and process their request. If they do not, do not process the request.

If we go back to our previous example (with our delete-account.php file), we can see that by requiring the CSRF token to be passed with the call (e.g. delete-account.php?csrfToken=5ghfido943zqs95akopq19gfsa), any forged link on a forum would not actually be able to delete the user’s account as it would not be able to pass the correct CSRF token. Additionally, by storing the CSRF token in the user’s session, they will receive a new token when their session expires.

Load Testing

We recommend using the following service to load-test your website/application: https://app.loadimpact.com

Open Source Rules!

At Parasol Island, we truly believe in the open source movement and, as such, follow what we like to call, The Open Source Rule. This rule depicts that all frontend-related tools be free of charge and available for everyone to use.

If, under very special circumstances, you find yourself needing to use a paid tool or service, you must ensure that the license is applicable to both yourself and Parasol Island (at no extra cost). If this is not possible, please speak to your Project Manager as a matter of urgency.