Web Developer Responsibilities Standard

Purpose

This standard defines the responsibilities the developer should take when developing a web site on Purdue-IT-hosted web servers.

Brief Description

Web Services’ goal is to provide a stable and secure web hosting environment. Web developers impact this goal through their activities and so have responsibilities they must fulfill. Web developers are expected to be aware of and abide by these responsibilities.

Details

Providing a stable and secure web experience is a collaborative effort between the Web Services staff and web developers. Web Services strives to provide a stable and secure platform, but web developers also have responsibilities. While many, these responsibilities fall into a few general categories:

  • Working with Web Services in a collaborative manner
  • Conforming with industry and University standards and practices
  • Using good coding and design practices to enhance or maintain security

In each of these areas, there are specific things that a web developer should do to make the overall environment function as smoothly as possible.

Working with Web Services in a Collaborative Manner

Web Services tries to balance the needs of each customer (web developer) to provide the best overall experience. When a web developer works with us, it generally results in smoother operations and a more pleasant experience. It also allows us more time to help find ways to make things work for the developer while preserving stability. To assist, a web developer should strive to:

  • Adhere to our published web standards. These standards define our service interface, set customer expectations, and communicate with our customers in a predictable and clear manner. By being aware of the standards we publish and trying to adhere to them, both parties benefit as expectations are well understood.
  • Request help when needed. Web Services knows our systems and tries to understand how developers want to use them. Often, if you seek help to understand our systems or for advice on how to work within the restrictions we’ve had to implement, we can guide you to a solution. We may not be able to troubleshoot your code, but we can tell you when your path sounds reasonable.
  • Inform Web Services as developers change. As staff move from project to project, department to department, or leave the University, it is important that old accesses are removed for security.
  • Report issues in a timely fashion. If Web Services is advised of an issue early, the range of options we have available to troubleshoot and resolve the issue (or keep it from spreading to production) are maximized. We may be able to correlate with events (patches, other outages, etc.), roll back a change, prevent a patch from going to production, restore a file from backups, or other possibilities. If, on the other hand, it has been weeks or months since the issue occurred, it is nearly impossible to do these tasks well. If possible, the time when the issue was first noticed is greatly appreciated.
  • Work with Web Services on troubleshooting. We know our systems – you know your site and code. Together, we should be able to find a solution. If you engage us to troubleshoot a problem, please ensure that you (or a knowledgeable co-worker) are available to work with us or we will not be able to help you. It is also vital that if you log error conditions to somewhere other than the standard system error logs (such as to a database), that you make those logs available to Web Services when you request our assistance.
  • Work within our development environments. Web Services provides development (and sometimes qa) systems that correspond closely to our production systems. This ensures that sites developed on our development system are likely to function correctly in production. When sites are developed elsewhere (perhaps on a 3rd-party server), there are no guarantees that things will go smoothly. As such, site owners are encouraged to have developers (especially external developers) work on our development servers. If a 3rd-party server is used for development, it is the responsibility of the site owner to work with the developer to move the site onto Web Services’ systems. Web Services does not have the resources to perform this work.
  • Manage the R4P accounts of external developers. When using the services of an external developer, it is the responsibility of the site owner to coordinate their R4P requests. This includes both the initial request and the annual renewal. To avoid disruption, this should be tracked carefully and the renewal process started early.

Conforming with Industry and University Standards and Practices

  • Evaluate and maintain accessibility for web sites. Purdue now has a policy that all public-facing web pages must be maintained as accessible to people with disabilities. It is the responsibility of the web site owner and developers to ensure that the site is accessible and the site should be re-evaluated on a periodic basis to ensure that it remains so.
  • Adhere to IT Policies. Purdue has policies related to the appropriate use of University IT resources, access, security, and a myriad of other topics. It is the responsibility of the web site owner and developers to review these policies and ensure that a web site is compliant. It is also their responsibility to keep abreast of changes and additions to these policies and to ensure that the web site continues to comply.
  • Follow SSL practices. Web Services provides and encourages the use of SSL for all web pages hosted by us. This allows visitors to be certain that the page is truly coming from Purdue, has not been altered in transit, and that any communications they have with the page (form submissions, logins, etc.) are secure and cannot be intercepted. For web site owners, you also gain the advantage of knowing that what the visitor submitted hasn’t been altered in transit as well. University policy also requires that all credentials used for login (or to track that a login has occurred) must be transmitted over encrypted channels (such as SSL). Because all sites are available over SSL, it is the responsibility of the owner and developers of a web site to implement their pages such that they work correctly over SSL, whether it is required or not. It is also their responsibility to advise us of pages or sections of sites that must be configured to use SSL. Failure to advise us of the need for SSL may result in visitors having their accounts compromised and will be the responsibility of the site owner.
  • Test code and review all site changes. Web Services provides development, qa, and production systems for all shared environments and encourages them for all. It is the responsibility of the web site owner and developers to test all code and review all changes before the site is promoted to production.

Using Good Coding and Design Practices to Enhance or Maintain Security

  • Support and maintain good site security. Web developers play a crucial role in maintaining the security of a web site. They often provide the first line of defense against malicious access attempts. It is critical that they follow good coding and design practices in their implementation. While not an exhaustive list, some things that a developer can do include:
    • Carefully plan out and use directory security. Web Services can configure various directory restrictions based on the visitor’s IP address or based on login information. It is the responsibility of the web developer to layout their site to take advantage of directory security and to clearly communicate with Web Services what types of security are needed where. Good directory security practices include:
      • Grouping files with like security needs into common directories
      • Ensuring that all components (CSS, JavaScript, images) required by a secured page are available to authorized visitors to the page
      • Ensuring that all components (CSS, JavaScript, images) required by a non-secured page are available to visitors of the page without requiring a login
    • Protect forms. If you provide a web-based form that generates an email message and you don’t protect the form in some fashion, you will receive SPAM because someone will find the form and abuse it. Likewise, if the form takes some other action (entering data into a database, for example), you will find that your database gets filled up with junk. Steps you can take to protect your forms are:
      • Use some form of Captcha
      • Embed special hidden form fields that a person would not fill in but a robot might
      • Put the form behind a login
    • Validate all input. Do not just validate the input in JavaScript in the browser. This is handy for providing feedback to the customer quickly about something they need to fix, but it does nothing to protect your application from malicious attacks. Instead, validate input in the browser (for quick customer feedback) and in your application on the web server (for security.) This should include validating the type and format of the data (a phone number should look like a phone number) and ensuring that a user cannot enter arbitrary data for some values. For example, do not allow a visitor to set the sender email address in a form (unless you want to answer why your form is sending email on behalf of the President). This validation should help to:
    • Run periodic security scans against your site. Purdue System Security (PSS) provides access to the  a web vulnerability scanning service, which you can use to test your site against an extensive array of vulnerabilities. Such scans are the responsibility of the web site owner or developer and Internal Audit requires that any site or application that handles any sensitive or restricted data must be scanned at least once per year. Web Services will not run these scans on your behalf. However, once you have your results, Web Services can assist you in interpreting the results (to help weed out false positives, for example). It is also important that you report any issues identified as a server configuration vulnerability to Web Services so that we may address those.
    • Never run code from an untrusted source. If you did not write the code or do not absolutely trust the author of the code, do not let it run in your web site! This includes code downloaded from the Internet, code you import (using PHP “include” for example), as well as code that might have been written into your database by some other application.
    • Protect your database credentials. Database connections are controlled by a username and password, much as logins to systems and sites are. These credentials should be treated with the same level of security that you would use for any personal credentials. Although these credentials must be known to your web site or application, you should take steps to protect them as described in our Web to Database Connection Standard.
  • Contribute to server security. While server security is primarily a system administrator responsibility, there are many things you can do to help us in this effort:
    • Do not share your account credentials! This is a violation of University policy in addition to poor practice.
    • Choose good passwords.
    • Inform Web Services of developers who should no longer have access to a site.
    • Do not set overly loose permissions on directories or folders. Ideally, you shouldn’t change the permissions from what we set by default. If you think you need to, please talk to us. Please be aware that some SFTP clients may alter permissions to non-default values. A complete list of these clients and what they do (and how to configure them to not do it) is beyond the scope of this document. Please talk to your IT support staff or research online.
    • Change shared group account passwords as needed. Some Cascade sites are published using group accounts. When staff leave who may have known the shared password, it should be changed.
    • When connected to the web server (via fileshare, ssh, sftp, etc.) or to a Content Management System (such as Cascade), be sure that you lock your screen whenever you leave your desk, no matter how briefly.