Skip to content

UFIT RC web application development standards

Coding and Development

  • If the application uses AI, machine-local or UF-assessed models, such as those hosted in Navigator AI, should be used. If AI services external to UF are being used, then a risk assessment should be opened for review.
  • Validate your input parameters. Log an error if input validation fails.
  • Linting tools must be used to eliminate common mistakes that can lead to application errors or even security vulnerabilities.  The lint checks must be completed with zero errors and as few warnings as possible. Examples:
    • Pylint
    • Mypy
    • PHP CLI – built in
  • Custom scripts and programs should use industry-standard logging formats.  Logs should contain one line per event and be stored in a location monitored by UFIT RC's log processing system.
  • Follow coding best practices for the programming language in question, using frameworks to ensure successful building, testing, and validation of code, e.g.
    • Python – Follow PEP 8 or current Python style guide
    • PHP – Configuration Cheat Sheet
    • perl - always 'use strict' and 'use warnings'
  • Attempt to avoid replicating code, as doing so, will increase the maintenance burden, but apply when needed to decrease excessive method coupling.
  • If a style guide exists for the language in question, read it and try to follow it.
  • If common idioms exist in the developer community for the language you are using, you should use them
  • If your program or tool interacts with a service running on another host don't forget to check for errors in the log for that service
  • Review the output of the tools to make sure that only information appropriate to the access level of people running it is presented. Do not output unnecessary information.
  • Do not gather and/or store information that's not necessary for Web App activities as information not collected cannot be exposed by malicious actors in the case of a break-in.
  • Use the principle of the least privilege (Cyberark What is Least Privilege, Principle of least privilege)
  • Secure protocols must be used for communications to/from any services - e.g., web services must use HTTPS, not HTTP; other client/server communications must be SSL encrypted, etc.  Read/write credentials of any type must never be passed over the network in the clear.  Client request traffic to the reverse proxy is encrypted by default. UFIT RC also provides a free *.rc.ufl.edu SSL certificate if requested by the customer. An SSL certificate for a custom domain can, in most cases, be requested at no cost through InCommon if requested by the customer in a support ticket. Each request will be reviewed individually.
  • Use a static code analysis tool (example: SAST) to check your code for known security vulnerabilities.  If possible, incorporate such tools into UF GitHub or other CI/CD providers for your project to automatically generate reports.  Development activity must not introduce any new potential vulnerabilities prior to deployment to production
    • Generate and maintain a software bill of materials (SBOM) for your web application. This content should be recorded, updated, and provided if necessary for review. Below are a couple of examples:
      • Syft - https://github.com/anchore/syft (for containers, recommended)
      • Microsoft SBOM Tool: https://github.com/microsoft/sbom-tool (more general)
    • Prior to deployment all application code, packages, and containers should be tested for vulnerabilities using a static code analysis tool. As many CVEs should be mitigated as possible and the remainder should be documented in the documentation for the web application. Below is an example tool that can be used:
      • Grype: https://github.com/anchore/grype
  • Consult the Common Weakness Enumeration List for common weaknesses to avoid in software development generally, as well as for specific programming languages. ◦ Review the latest top 25 list of most dangerous software weaknesses: CWE Top 25 Most Dangerous Software Weaknesses ◦ Make sure your code does not fall victim to them.
  • See the OWASP Secure Coding Practices-Quick Reference Guide Secure Coding Practices Checklist for additional specific items to check. 
  • UFIT regularly scans internal websites, external websites, and web applications for network-exposed vulnerabilities that are present and exploitable through the network.  They use various techniques, scanners, and technologies for these analysis tasks.   
    • All web applications will be continually scanned by these tools, and any vulnerabilities exposed on the network that are classified as Critical or High will need to be mitigated or patched within the timelines maintained by UFIT.  These timelines will vary depending on the criticality and current exploitation status.   
    • Web applications will be disabled or have access limited to the research group or other groups participating in the remediation of the vulnerabilities. The customer will be notified when this happens.  The applications will need to be rescanned and confirmed to no longer have these vulnerabilities before public access can be resumed.