Choose methods, status codes, redirects and cache behaviour deliberately.
Project-based Internship Programme
Build and Test a Secure URL Shortener Backend API
This backend development online internship with certificate is a fee-based, project-based internship programme that focuses on a secure URL shortener REST API. You implement endpoint contracts, persistence, ownership controls, validation, rate limiting, structured errors, logging and a bounded malicious-link risk classification step without fetching submitted destinations. The project is server-side and does not claim to provide complete threat detection.
Decision note 01
Is API reliability the engineering depth you want?
A useful fit if…
- You want to concentrate on HTTP contracts, server validation, database behaviour and operational controls.
- You are ready to test collisions, malformed input, rate limits and degraded dependencies rather than only successful requests.
- You can treat submitted URLs as inert strings and avoid contacting unknown destinations.
Choose another route if…
- You mainly want to design a React interface or own an end-to-end storefront.
- You intend to visit submitted URLs during classification, which is outside the safe project boundary.
- You expect paid work, employment or guaranteed institutional credit.
Official assigned project
Secure URL Shortener API
The Secure URL Shortener API turns a simple redirect into a service-design exercise. Creating a short link requires input validation, unique-code handling, ownership and durable storage. Redirect lookup needs predictable status behaviour and safe logging. Abuse controls must constrain request volume, while the risk-classification step operates on URL text only and has a documented fallback when its classifier is unavailable.
Task brief
Secure URL Shortener API — Build a documented REST API for URL creation, persistence, rate limiting, and malicious-link risk classification.
Catalogue deliverables
- Runnable API
- persistence schema
- endpoint documentation
- tests
- and setup guide
Your build path
Harden the service one boundary at a time
Define URL creation, lookup and redirect contracts with consistent status and error responses. Define request fields, response bodies, status codes, authentication needs and error shapes for creation, lookup, redirect and management.
Validate URL strings without visiting targets, create unique codes and persist ownership and timestamps. Choose code uniqueness, owner relationships, timestamps and indexes, then test persistence across process restarts.
Add authentication or ownership controls for protected management actions. Parse and constrain URL strings without navigating to them, and keep classifier features limited to documented text structure.
Apply rate limits, structured logging and a bounded risk-classification fallback. Implement rate limits, structured logs, protected configuration and consistent dependency-failure behaviour.
Test malformed input, collisions, redirects, limits, persistence and degraded classifier behaviour. Exercise malformed strings, code collisions, missing records, unauthorized changes, excessive requests and classifier fallback locally.
Private self-check
Check your server-side testing readiness
Your answers remain in this browser tab and are not stored or sent.
Use these prompts for reflection; they are not an eligibility test.
Skills notebook
Develop API, persistence and operational controls
These are general domain-learning suggestions, not confirmed HireeBridge tool requirements.
API contracts
Reject malformed or unsupported URL strings with consistent field errors.
Return stable machine-readable failures without leaking internal details.
Data and access
Store original URL, short code, owner and timestamps under explicit constraints.
Establish identity for protected management operations.
Enforce ownership and administrative permissions on the server.
Operations
Bound abuse with testable policies and clear responses.
Record request and failure context without secrets or unnecessary personal data.
Keep classification failure distinct from URL validity and service availability.
Review before submitting
Backend failure modes to catch before review
- 01
Checking URL shape with a network request
The task says not to visit submitted destinations. Treat them as strings and document lexical or structural classification only.
- 02
Generating codes without collision handling
A random result still needs a uniqueness constraint and a retry or conflict strategy.
- 03
Applying rate limits after expensive work
Reject excessive traffic early and test the documented scope, key and response headers.
- 04
Logging secrets or complete sensitive values
Logs should support diagnosis while minimising tokens, credentials and unnecessary submitted data.
- 05
Returning a successful risk label when classification fails
Expose a bounded fallback or unavailable state instead of silently treating an error as safe.
What reviewers check
Completeness against the assigned brief and deliverables; functional correctness; domain-relevant logic, data, metrics or implementation; required edge cases and failure handling; reproducible setup and submission evidence; and clear documentation of the completed work.
Reviewer
GreyRocks team
Catalogue validation notes
Cover code uniqueness, malformed URLs, redirects, rate limits, and classifier fallback behavior.
Evidence language
Record backend work as verifiable evidence
Keep placeholders until you can replace them with evidence from your own project.
- Designed [number] REST endpoints with consistent status codes, validation errors and API documentation.
- Implemented unique short-code persistence with database constraints and tested collision behaviour.
- Enforced authentication and owner authorization for [operation] while keeping public redirects bounded.
- Added rate limiting and structured logs, verifying [limit condition] without recording secrets.
- Built an inert-string risk classification step with explicit fallback and no outbound target requests.
Project readiness
Prepare a strong project submission
Certificate and verification
Prove service behaviour before credential approval
A certificate is not created by payment or API deployment. Submit the service, tests and evidence for review; explicit approval enables the GreyRocks record with a unique credential ID and QR verification destination. The certificate does not certify a security product or promise detection of every malicious URL.
- Complete
- Submit
- Review
- Approval
- Credential ID and QR
Read the certificate process · Verify a credential on GreyRocks
Duration: 1 Month / 4 Weeks.
Plan inclusions: Each domain maps to an assigned project and task specification. Reference repositories and comprehensive materials depend on the selected plan; certificates follow task submission and explicit reviewer approval.
Questions from students
Backend Development internship FAQ
What is the assigned Backend project?
The catalogue assigns a secure URL shortener REST API with persistence, rate limiting and a bounded malicious-link risk classification step.
May the service visit submitted URLs?
No. The catalogue says the classifier should work without visiting the destination. Treat input as inert text.
How should short-code collisions be handled?
Use a database uniqueness constraint plus a documented retry or conflict response strategy.
Does the project need authentication?
Ownership or protected management actions need server-side identity and authorization controls.
What should happen if classification is unavailable?
Return a documented fallback or unavailable state; do not silently label the URL safe.
Which tests are essential?
Cover malformed strings, uniqueness, persistence, redirects, missing records, authorization, rate limits and classifier fallback.
When is the certificate created?
After submission and explicit approval.
Does this programme guarantee academic credit?
No. Confirm the institution’s requirements first.
Next step
Choose your plan and start building.
Review plan details, included resources and the assigned project scope before you begin.