WGU D385 ZHN1 Task 1
Software Security and Testing
Static Code Analysis, Logging, Debugging, and Defensive Programming
Application examined: Python/Flask equipment rental system
Scope: This report analyzes an independently built Flask rental application. The WGU starter files were not available for a direct
source-code comparison.
A. Analysis of the Python Application
A1. Static Code Analysis
Static code analysis examines source code without running the program. It is useful during development
because weaknesses can be found while they are still relatively inexpensive to correct. The review may uncover
unsafe handling of user input, exposed secrets, weak exception handling, insecure configuration, and
programming errors that would otherwise remain unnoticed until testing or deployment. Automated
static-analysis tools can flag recognizable patterns, while manual review is needed to understand the
application’s business rules and determine whether a reported issue is a genuine risk (OWASP, n.d.-a).
In this application, the two areas most likely to be affected by untrusted input are the login form and the
equipment rental form. Login requests supply a username and password, while rental requests supply an
equipment identifier and the number of rental days. Both forms create opportunities for unexpected values to
reach application logic. Reviewing how those values are accepted, checked, and processed is therefore an
important part of assessing the program.
Static analysis is a starting point rather than a guarantee of security. It cannot, by itself, demonstrate that a page
runs correctly, that an error handler is reached, or that a log entry is produced when an exception occurs. Those
claims require execution and testing. For that reason, the review in Section A is followed by an implementation
and test plan in Sections B and C.
A2. Types of Issues Detected by Static Analysis
Improper input validation
A rental duration is expected to be a positive whole number. If the program sends the value directly into an
integer conversion or price calculation without checking it, a nonnumeric entry could produce an error and a
negative value could produce an invalid charge. Static review can identify places where request data is used
without appropriate validation. The implementation checks both the data type and the permitted range before
calculating a rental cost.
WGU D385 ZHN1 Task 1 1
, Hardcoded secrets and credentials
Passwords and application secrets should not be exposed unnecessarily in source code. A Flask session secret,
for example, protects the integrity of signed session information. Static analyzers may identify obvious
embedded passwords or secrets; manual inspection is still required to decide how the values are used. In the
demonstration implementation, the login password is supplied through an environment variable, and the
application supports an externally configured Flask secret.
Improper exception handling
An exception can arise even in a small application. Looking up an equipment identifier that is not in a dictionary
raises a KeyError. Converting a nonnumeric string to an integer raises a ValueError. If those conditions are not
handled, the request may fail in a way the user cannot understand. The relevant issue is not merely whether an
exception occurs, but whether the program recovers from an expected error and avoids exposing internal details.
Security misconfiguration
Development settings are not necessarily appropriate for production. Flask debug mode can expose sensitive
diagnostic information and should not be enabled on a public deployment. The reconstructed application runs
with debug mode disabled and avoids writing authentication secrets to the log. Configuration review is still
necessary before any real deployment.
Unused code and unreliable program logic
Unused branches, duplicated routines, and inconsistent checks make a program harder to inspect and maintain.
They may also conceal mistakes in security-sensitive paths. A static analyzer can report some of these defects.
Manual review provides a second opportunity to check whether the validation and authentication logic follow
the intended order.
A3. Issues Identified in the Supplied Application Reference
The supplied D385 Task 1 reference reports five concerns in a Flask-based equipment rental system: missing
structured logging, a hardcoded secret, insufficient input validation, missing exception handling, and a limited
response to suspicious activity. These findings are summarized here as reported observations; the original WGU
application files were not available for independent code inspection.
1. Missing structured logging
Without a reliable event record, it is difficult to determine why a login failed or why a rental calculation did not
complete. I addressed this concern in the reconstructed application by configuring Python logging at the INFO
level and recording the event together with the action taken by the program. Authentication results, input
rejections, and successful calculations are each given a consistent message.
2. A secret embedded in the application
The reference identifies a hardcoded session secret. A disclosed signing key creates an unnecessary risk because
session data can no longer be trusted in the same way. The demonstration reads FLASK_SECRET_KEY from
its environment when one is provided, rather than depending on a fixed value in the source. A secure, persistent
key and managed storage would be necessary for a deployed system.
WGU D385 ZHN1 Task 1 2
, 3. Insufficient validation of form data
A normal rental request should use an approved equipment name and a positive integer for rental days.
Accepting any submitted value makes the calculation vulnerable to both mistakes and manipulated requests.
The revised rental route rejects identifiers outside the equipment price list and rejects missing, nonnumeric,
zero, or negative day values before calculating the total.
4. Missing handling for expected runtime errors
A KeyError or ValueError should not prevent the application from giving a controlled response. The
reconstructed route catches an unknown equipment identifier separately from invalid rental days. This
separation is useful because the two conditions have different causes and do not require identical log severity.
5. Limited visibility of suspicious requests
The reference also discusses requests that could indicate suspicious activity. One failed login does not prove an
attack, and a mistyped rental day is usually a routine input error. Repeated events, however, can be meaningful
when reviewed together. The application logs invalid credentials and unexpected equipment values so that such
patterns can be recognized during investigation. It does not claim to provide a complete intrusion-detection or
rate-limiting system.
B. Application Changes and Testing
B1. Application Logging
I used Python’s logging module so that the application has a record of the operations that matter for
troubleshooting. The file is named Troubleshooting_DEMO.log in the demonstration project. INFO is the
minimum configured severity, allowing informational messages, warnings, and errors to be written to the same
file. Each entry includes its date and time, severity, and the event/action message (Python Software Foundation,
n.d.).
format='%(asctime)s - %(levelname)s - %(message)s'
level=logging.INFO
message='EVENT: [description] | ACTION: [response]'
The logging helper accepts a severity level, an event, and an action. This keeps the text consistent across routes.
The program records successful and unsuccessful logins; successful assertions; valid calculations; invalid
equipment; invalid rental days; and requests that reach the rental page without a signed-in session. It does not
write passwords, tokens, or session secrets to the log. This exclusion follows OWASP’s guidance for security
logging (OWASP, n.d.-b).
Logging is useful only if the recorded information is meaningful. For instance, “invalid input” alone gives little
diagnostic value. A message such as “Unknown equipment identifier | Reject unapproved equipment” shows
both the problem and the application’s response. The entries should be examined after local execution to verify
that the configured file is actually receiving the expected records.
WGU D385 ZHN1 Task 1 3
Software Security and Testing
Static Code Analysis, Logging, Debugging, and Defensive Programming
Application examined: Python/Flask equipment rental system
Scope: This report analyzes an independently built Flask rental application. The WGU starter files were not available for a direct
source-code comparison.
A. Analysis of the Python Application
A1. Static Code Analysis
Static code analysis examines source code without running the program. It is useful during development
because weaknesses can be found while they are still relatively inexpensive to correct. The review may uncover
unsafe handling of user input, exposed secrets, weak exception handling, insecure configuration, and
programming errors that would otherwise remain unnoticed until testing or deployment. Automated
static-analysis tools can flag recognizable patterns, while manual review is needed to understand the
application’s business rules and determine whether a reported issue is a genuine risk (OWASP, n.d.-a).
In this application, the two areas most likely to be affected by untrusted input are the login form and the
equipment rental form. Login requests supply a username and password, while rental requests supply an
equipment identifier and the number of rental days. Both forms create opportunities for unexpected values to
reach application logic. Reviewing how those values are accepted, checked, and processed is therefore an
important part of assessing the program.
Static analysis is a starting point rather than a guarantee of security. It cannot, by itself, demonstrate that a page
runs correctly, that an error handler is reached, or that a log entry is produced when an exception occurs. Those
claims require execution and testing. For that reason, the review in Section A is followed by an implementation
and test plan in Sections B and C.
A2. Types of Issues Detected by Static Analysis
Improper input validation
A rental duration is expected to be a positive whole number. If the program sends the value directly into an
integer conversion or price calculation without checking it, a nonnumeric entry could produce an error and a
negative value could produce an invalid charge. Static review can identify places where request data is used
without appropriate validation. The implementation checks both the data type and the permitted range before
calculating a rental cost.
WGU D385 ZHN1 Task 1 1
, Hardcoded secrets and credentials
Passwords and application secrets should not be exposed unnecessarily in source code. A Flask session secret,
for example, protects the integrity of signed session information. Static analyzers may identify obvious
embedded passwords or secrets; manual inspection is still required to decide how the values are used. In the
demonstration implementation, the login password is supplied through an environment variable, and the
application supports an externally configured Flask secret.
Improper exception handling
An exception can arise even in a small application. Looking up an equipment identifier that is not in a dictionary
raises a KeyError. Converting a nonnumeric string to an integer raises a ValueError. If those conditions are not
handled, the request may fail in a way the user cannot understand. The relevant issue is not merely whether an
exception occurs, but whether the program recovers from an expected error and avoids exposing internal details.
Security misconfiguration
Development settings are not necessarily appropriate for production. Flask debug mode can expose sensitive
diagnostic information and should not be enabled on a public deployment. The reconstructed application runs
with debug mode disabled and avoids writing authentication secrets to the log. Configuration review is still
necessary before any real deployment.
Unused code and unreliable program logic
Unused branches, duplicated routines, and inconsistent checks make a program harder to inspect and maintain.
They may also conceal mistakes in security-sensitive paths. A static analyzer can report some of these defects.
Manual review provides a second opportunity to check whether the validation and authentication logic follow
the intended order.
A3. Issues Identified in the Supplied Application Reference
The supplied D385 Task 1 reference reports five concerns in a Flask-based equipment rental system: missing
structured logging, a hardcoded secret, insufficient input validation, missing exception handling, and a limited
response to suspicious activity. These findings are summarized here as reported observations; the original WGU
application files were not available for independent code inspection.
1. Missing structured logging
Without a reliable event record, it is difficult to determine why a login failed or why a rental calculation did not
complete. I addressed this concern in the reconstructed application by configuring Python logging at the INFO
level and recording the event together with the action taken by the program. Authentication results, input
rejections, and successful calculations are each given a consistent message.
2. A secret embedded in the application
The reference identifies a hardcoded session secret. A disclosed signing key creates an unnecessary risk because
session data can no longer be trusted in the same way. The demonstration reads FLASK_SECRET_KEY from
its environment when one is provided, rather than depending on a fixed value in the source. A secure, persistent
key and managed storage would be necessary for a deployed system.
WGU D385 ZHN1 Task 1 2
, 3. Insufficient validation of form data
A normal rental request should use an approved equipment name and a positive integer for rental days.
Accepting any submitted value makes the calculation vulnerable to both mistakes and manipulated requests.
The revised rental route rejects identifiers outside the equipment price list and rejects missing, nonnumeric,
zero, or negative day values before calculating the total.
4. Missing handling for expected runtime errors
A KeyError or ValueError should not prevent the application from giving a controlled response. The
reconstructed route catches an unknown equipment identifier separately from invalid rental days. This
separation is useful because the two conditions have different causes and do not require identical log severity.
5. Limited visibility of suspicious requests
The reference also discusses requests that could indicate suspicious activity. One failed login does not prove an
attack, and a mistyped rental day is usually a routine input error. Repeated events, however, can be meaningful
when reviewed together. The application logs invalid credentials and unexpected equipment values so that such
patterns can be recognized during investigation. It does not claim to provide a complete intrusion-detection or
rate-limiting system.
B. Application Changes and Testing
B1. Application Logging
I used Python’s logging module so that the application has a record of the operations that matter for
troubleshooting. The file is named Troubleshooting_DEMO.log in the demonstration project. INFO is the
minimum configured severity, allowing informational messages, warnings, and errors to be written to the same
file. Each entry includes its date and time, severity, and the event/action message (Python Software Foundation,
n.d.).
format='%(asctime)s - %(levelname)s - %(message)s'
level=logging.INFO
message='EVENT: [description] | ACTION: [response]'
The logging helper accepts a severity level, an event, and an action. This keeps the text consistent across routes.
The program records successful and unsuccessful logins; successful assertions; valid calculations; invalid
equipment; invalid rental days; and requests that reach the rental page without a signed-in session. It does not
write passwords, tokens, or session secrets to the log. This exclusion follows OWASP’s guidance for security
logging (OWASP, n.d.-b).
Logging is useful only if the recorded information is meaningful. For instance, “invalid input” alone gives little
diagnostic value. A message such as “Unknown equipment identifier | Reject unapproved equipment” shows
both the problem and the application’s response. The entries should be examined after local execution to verify
that the configured file is actually receiving the expected records.
WGU D385 ZHN1 Task 1 3
